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Preface 


This  document  gives  an  overview  of  the  Second  PCIS  (Portable  Common  Interface  Set) 
Workshop,  held  3-7  June  1991  in  Redondo  Beach,  CA.  It  is  intended  to  be  used  as  a  major  source 
of  technical  input  to  the  further  refinement  of  requirements  for  the  International  Requirements  and 
Design  Criteria  (IRAC)  for  a  Portable  Common  Interface  Set,  as  well  as  input,  both  technical  and 
programmatic,  for  the  “way  forward"  of  the  PCIS  Programme.  This  document  is  directed  to  the 
participants  of  the  aforementioned  Workshop,  the  PCIS  International  Experts,  and  the  management 
team  of  the  PCIS  Programme. 

This  document  pertains  to  the  requirements  of  the  Statement  of  Work,  items  d.  and  e.,  of 
Task  Order  T-D5-496  (Amendment  No.  5),  NATO  Special  Woridng  Group  (SWG)  on  Ada 
Programming  Support  Environments  (APSE),  which  request  IDA  to 

d.  “Provide  technical  assessments  concerning  SWG  on  APSE  software  interface  activities 
to  the  US  Representative  on  the  IRB  of  the  SWG  on  APSE;  these  include  technical 
analyses  of  interface  technologies  for  APSEs,  including  CAIS-A,  PCTE+,  and  others 
(e.g.,ECMAPCTE)." 

e.  “Interface  with  the  PCIS  Expert  Tbam  to  perform  technical  reviews  of  the  products 
developed  by  the  PCIS  Expert  Tbam;  provide  programme  leadership  and  guidance  to 
members  of  the  PCIS  Experts  Team  and  to  PCIS  Expert  Reviewers  in  the  development 
of  these  products.” 
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EXECUTIVE  SUMMARY 


This  document  contains 
blank  pages  that  were 
not  filmed 


The  Second  PCIS  Workshop,  in  conjunction  with  the  5th  NIST  ISEE  Workshop  and  the 
IWCASE  Workshops,  was  held  in  Redondo  Beach,  California  from  3-7  June  1991.  The 
workshops  were  hosted  by  TRW  and  the  Los  Angeles  SIGAda  and  sponsored  by  the  U.S. 
Department  of  Defense,  the  Ada  Joint  Program  Office  (AJPO),  the  National  Institute  of  Standards 
and  Technology  (NIST),  the  U.S.  Department  of  Conunerce,  the  NATO  Special  Working  Group 
on  Ada  Programming  Support  Environments  (NATO  SWG  on  APSE),  and  the  International 
Workshop  on  CASE  (IWCASE). 

The  primary  goals  of  the  PCIS  Requirements  Validation  Phase  arc  to- 

o  Gather  requirements  from  the  software  engineering  environment  (SEE) 
community, 

o  Validate  requirements  defined  in  the  NATO  Requirements  and  Design  Criteria 
(NRAC),  and  survey  available  or  emerging  technologies, 

o  Produce  the  International  Requirements  and  Design  Criteria  (IRAQ  and  Interface 
Technology  Analysis  (TTA)  document,  and 

o  Propose  a  way  forward  for  the  PCIS  Programme  to  the  NATO  SWG  on  APSE, 
the  PCIS  Programme’s  sponsoring  organization. 

The  workshops  were  aU  very  important  and  complementary  to  the  PQS  Programme.  The 
reference  model  work  of  the  NIST  ISEE  Workshop  is  complementary  in  that  it  identifies  a 
superset  of  the  services  likely  to  be  provided  in  a  PCIS  environment  firamework.  It  also  provides 
a  context  in  which  to  compare  several  existing  or  emerging  systems  of  interest  to.  the  PCIS 
Programme.  The  IWCASE  Workshop  supports  the  second  SWG  on  APSE  goal  by  providing 
information  about  emerging  technology  relevant  to  the  PCIS  Programme. 

The  goal  of  the  NIST  ISEE  program  is  to  identify  and  establish  a  consensus  for  U.S. 
Federal  government  and  industry  to  take  in  addressing  the  need  for  open  system  ISEE  and 
software  tools  interface  standards.  The  current  NIST  work  on  software  engineering  environment 
issues  centers  on  Workshops  on  Integrated  Software  Engineering  Environments  (ISEE).  The  goal 
is  to  provide  guidance  to  Federal  agencies  in  acquiring  ar?  ISEE.  The  current  NIST  ISEE 
Reference  Model  defines  the  "concept"  of  an  ISEE  in  terms  of  services  and  dimensions.  Most 
of  the  items  which  are  defined  originated,  for  the  most  part,  in  the  ECMA  Technical  Report,  "A 
Reference  Model  for  Computer  Assisted  Software  Engineering  Envirorunent  Frameworks,"  which 
was  approved  by  ECMA  TC33,  September  1990.  However,  some  of  the  definitions  have  been 
created  by  the  NIST  ISEE  Working  Group  through  its  extension  and  modifications  to  the  ECMA 
Reference  Model  Document.  NIST  is  plarming  to  publish  the  'TSEE  Reference  Model  Technical 
Report,"  version  1.0,  as  well  as  the  "Report  on  Summary  of  Results  of  the  first  NIST  ISEE 
Reference  Model  Mapping"  by  the  end  of  September  or  early  October,  1991.  NIST  will  continue 
the  harmonization  of  joint  efforts  with  ECMA  TC33  to  develop  a  standard  ISEE  for  open  system 
environments  and  will  continue  tire  effort  of  working  towards  a  full  ISEE  development. 

The  objectives  of  the  IWCASE  Workshop  are  to  update  standardization  working  groups 
with  status  of  other  woridng  group  progress  and  to  identify  overltqrping  issues  and  facilitate 
coordination  on  these  issues  among  these  groups. 
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SECTION  I  «  NIST  ISEE  Workshop 


National  Institute  for  Science  and  Technology 
Integrated  Software  Engineering  Environment 
NIST  ISEE  Workshop 

ECMA  Organisation 

“  Hugh  Davis,  ICL 

Next  Generation  Computer  Resources  (NGCR): 

Project  Support  Environment  Working  Group  (PSEWG) 

-  Tricia  Obcmdorf,  NADC 

Reference  Model  Mappings 

Feedback  from  AD/Cycle  Mapping 

-  Bob  Ekman  for  B.  F.  Meyers,  IBM 
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-  Geoff  Clow,  SofTech 

Software  Life  Cycle  Support  Environment  (SLCSE) 

-  James  Milligan,  AFSC  Rome  Laboratory 

CIS  Experience  in  ECMA  Reference  Model  Mapping 

-  Hal  Pierson,  SPL 

Summary  of  Reference  Model  Evaluation 

-  Marvin  V.  Zelkowitz,  NIST 
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-  Tricia  Obemdorf,  NADC 

Object  Management  Working  Group  Summary 

-  Ix)lo  Pcnedo,  TRW 

Project  Management  Subgroup  Summary 

-  Hal  Hart,  TRW 


User  Interface  Management  Services  Summary 

-  Bob  Bagwell,  NIST 

Summary  of  the  5th  Workshop  on  Integrated  Software  Engineering  Environments  (ISEE) 

-  Bill  Wong,  NIST 
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SECTION  II  -  IWCASE  Workshop 


International  Workshop  on  CASE  (IWCASE) 

-  David  Sharon,  CASE  Associates 


CASE  Standards  Coordination  Update  Meeting 
Standard  Update  Reports 

-  David  Sharon,  CASE  Associates 


CALS,  PDES  and  Software  Products 
-  Tom  Baker,  Boeing 


CDIF 

-  Richard  Good,  MITRE 

PDES  STEP  CALS 

-  Tom  Baker,  Boeing 

BEEE-CS  PI  175  -  A  Standard  Reference  Model  for  Computing  System  Tool  Interconnection 

-  David  Sharon,  CASE  Associates 


CIS  and  ATIS 

-  Eric  Black,  Athenon  Technology 

Project  Support  Environment  Standaids  Working  Group  (PSESWG) 

-  Tricia  Oberadorf,  NADC 

The  COHESION  Framework  Program 

-  Ed  Cuoco,  DEC 

AD/Cycle  Platform:  Blueprint  for  a  More  Productive  Future 

-  Bob  Ekman,  IBM 

The  SoftBench  Experience 

-  I>r.  Huw  Oliver,  Hewlett-Packard 

Adding  Control  Integration  to  PCTE 

—  Dr.  Huw  Oliver,  Hewlett-Packard 

MIF  Control  Integration  Reactive  Integration  (Implicit  Invocation) 

-  Dr.  Robert  Balzer,  USC-ISI 

Infontiation  Resource  Dictionary  Systems  (IRDS) 

-  Dr.  James  Emerson,  RTI  [unable  to  attend;  slides  in  document] 
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SECTION  in  --  PCIS  Workshop 

Needs  of  the  Environment  User 

Caught  in  the  Minefield  (35inm  slides)  [not  included] 

-  David  Robinson,  SD  Scicon  for  Mark  Gibbons,  BT 

US  Air  Force:  The  Software  Technology  Suppon  Center 

-  Bob  Hanrahan,  USAF 

US  Army:  Software  Engineering  Requirements  for  the  Strategic  Defense  System 
Jackie  Christina,  USASDC 

Needs  of  PCTE  Programme:  A  Personal  View 

-  Hugh  Davis,  ICL 

SEMATECH’s  Advanced  Development  Environment  fADE),  or 
Software  Engineering  Environments:  The  Needs  of  Manufacturing  Users 

-  Claude  Baudoin,  SEMATECH 

Environments  --  An  Industry  View 

-  Leigh  Power,  MCC 

Environment  Users  Presentation 

-  Tim  ShoiTOck,  British  Aerospace  &  Dave  Robinson,  SD  Scicon 
PCIS  Wrap-Up  Sessions 

Report  of  the  Environment  Users  Session  -  Dr.  Tim  Lindquist,  Arizona  State  University 
Presentations 

Process  Driven  Requirements,  evolution  and  lego  interfaces 

-  Dr.  Vic  Stenning,  Anshar 
Role-based  Requirements  Analysis 

•  -  John  Leary  ,  Martin  Marietta 
Needs  for  PCIS  Administrative  Services 
Judy  Keraer,  Aerospace  Corp. 

Tlie  Requirements  Process:  Technology  Push  versus  User  Pull 

-  Claude  Baudoin,  SEMATECH 
Stability,  Systems  Engineering  and  Benefits 

—  Robert  Rankin,  DRA  RSRE,  for  M.  Morron 
Identifying  Methods  and  Tools 

-  Audrey  Canning,  ERA  Technology 

Report  of  the  Environment  Suppliers  Working  Group  -  Geoff  Clow,  SofTech 
Presentations 

ATIS  /  PCTE  Merger  Experiment 

-  Chris  Nolan,  DEC 
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Report  itf  the  Platform  Providers  [merged  with  Environment  Suppliers] 

Presentations 

PCIS  Working  Group  Needs  of  Platform  Providers 

•  Burt  Rubenstein,  Group  Software  Technology 

Report  of  the  Tool  Users  /  Builders  Working  Group  --  Herman  Fischer,  Mark  V  Systems 
Presentations 

PCIS  Needs  of  the  Tool  Builders 
-  Nicholas  Wybolt,  Cadre 


THE  INTERFACE  TECHNOLOGY  ANALYSIS  (ITA)  DOCUMENT 


This  Interface  Technology  Analysis  (ITA)  document  is  divided  into  three  main  sections, 
each  corresponding  to  one  of  the  Workshops  described  above.  An  introductory  section  giving 
an  overview  of  the  PCIS  and  NIST  ISEE  activities  is  included  first.  Section  I  contains 
presentations  and  summary  reports  of  the  NIST  ISEE  Workshop;  section  II  contains  presentations 
on  current  standards  activities  in  the  IWCASE  workshop,  and  section  III  contains  presentations 
and  summary  repons  of  working  groups  of  the  PCTS  Workshop.  Working  groups  met  in  parallel 
sessions  during  the  PCIS  and  NIST  ISEE  Workshops. 


POINTS  OF  CONTACT 

A  copy  of  the  ECMA  Reference  Model  document,  A  Reference  Mode!  for  Frameworks 
of  Computer-Assisted  Software  Engineering  Environments,  ECMA  TR/5S,  December  1990,  and 
a  copy  of  the  NIST  Reference  Model  document,  A  Reference  Model  for  Computer  Assisted 
Software  Engineering  Environment  Frameworks,  NIST  version  l.Oe,  May  29,  1991,  were 
distributed  as  pan  of  the  package  of  materials  which  everyone  received  at  the  Workshop.  Free 
copies  of  the  ECMA  Reference  Model  document  can  be  obtained  from: 

ECMA 

European  Computer  Manufacturers  Association 
114  Rue  du  Rhone 
CH-1204  Geneva 
Switzerland 

Copies  of  the  NIST  Reference  Model  document  can  be  obtained  by  contacting: 

Mr.  William  Wong 
NIST 

Bldg.  225,  Room  B266 
Gaithersburg,  MD  20899 
USA 

Additional  copies  of  this,  the  Interface  Technology  Analysis  (ITA)  document  can  be 
obtained  by  contacting  (in  North  America): 

Mr.  Clyde  Roby 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria,  VA  22311-1772 
USA 
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or  (in  Europe): 


Mr.  Ken  Hayter 

Defence  Research  Agency  (UK) 

RSRE 

St.  Andrews  Rd. 

Malvern 
Worcestershire 
WR14  3  PS 
UNITED  KINGDOM 

Video  and  Audio  tapes  of  the  plenary  sessions  were  made  during  the  meeting.  Contact 
(in  North  America)  Clyde  Roby  at  the  address  given  above,  or  (in  Europe): 

Mr.  John  Dawes 
ICL 

Eskdale  Road,  Winnersh 
Wokingham 
Berkshire  RGll  5TT 
UNITED  KINGDOM 

for  copies  of  audio  or  video  tapes. 


EDITOR’S  REMARKS 

The  contents  of  this  document  reflect  the  fact  that  three  "working"  Workshops  were  held. 
As  is  expected  in  such  workshops,  several  vugraphs  were  hand-drawn  and  many  of  these  were 
produced  in  real  time  in  the  Working  Sessions  and  Working  Groups,  so  their  quality  is  not 
always  the  best  Also,  not  all  slides  have  the  same  quality;  some  were  reproduced  horn  the 
actual  vugraphs,  others  were  reproduced  from  hardcopy.  The  editor  appreciates  the  hard  work 
in  the  preparation  of  all  materials  present  in  this  document. 

The  editor  is  particularly  grateful  to  the  chairs  of  all  the  working  groups  and  the  working 
sessions  of  all  the  workshops  for  helping  make  this  document  possible.  In  particular,  the  editor 
would  like  to  thank  Mr.  Bill  Wong,  Mr.  Currie  Colket,  Mr.  Gary  Pritchett,  and  Mr.  John  Dawes 
for  assistance  in  the  final  contents  of  this  Interface  Technology  Analysis  (ITA)  document. 


THE  PCIS  WORKSHOPS 


At  the  NATO  Special  Working  Group  (SWG)  on  Ada  Programming  Support 
Environments  (APSE)  meeting  in  San  Diego  in  December  1990,  the  SWG  agreed  to  pursue  an 
international  co-operative  programme  with  the  goal  of  defining  a  Portable  Common  Interface  Set 
(PCIS).  The  fusion  of  military  and  civil  (commercial)  requirements  is  seen  as  essential  to  ensure 
^at  PCIS  will  be  a  viable  standard  for  next  generation  environments.  Therefore,  before  the  PCIS 
Definition  Programme  commences,  a  Requirements  Phase  is  necessary  in  order  to  take  into 
account  the  needs  of  the  military  and  civil  communities.  This  Phase  has  four  objectives: 

o  The  validation  of  the  existing  NATO  Requirements  and  Design  Criteria  (NRAC) 
and  inclusion  of  non-military  requirements. 

o  An  investigation  into  what  is  being  provided  by  existing  interface  technology  and 
an  assessment  of  the  perceived  emerging  technology  over  the  next  five  years. 

o  A  comparison  of  the  results  with  that  which  industry  is  currently  providing. 

o  An  analysis  of  the  differences  leading  to  a  prioritization  and  costing  of  future 
work. 

Two  public  workshops  were  held  to  support  the  first  two  objectives.  The  First  PCIS 
Workshop  was  held  in  the  U.K.  during  the  week  of  29  April  to  3  May  1991.  The  Second  PCIS 
Workshop  was  held  in  California  during  the  week  cf  3-7  June  1991. 

Professor  John  Buxton,  chairman  of  the  First  PCIS  Workshop,  said  that  one  starting  point 
for  identifying  requirements  is  to  consider  the  principal  aim  of  software  engineering  as  one  of 
improving  the  quality  of  software.  In  achieving  quality,  it  is  essential  to  link  military  and 
commercial  requirements  for  environments  because  successful  commercial  software  is  likely 
to  be  software  that  is  widely  and  extensively  used,  with  the  result  that  its  defects  are  more  likely 
to  have  been  detected.  As  a  consequence,  the  background  aim  of  the  PCIS  Programme,  which 
is  to  bring  together  the  requirements  of  the  military  and  commercial  communities,  should  be 
regarded  as  a  major  step  towards  acliieving  quality  in  itself. 

The  PCIS  Workshops  were  organized  into  general  sessions  and  Working  Group  sessions. 
The  general  sessions  provided  presentations  on  emerging  technology  and  the  needs  of  special 
interests.  These  general  sessions  were  aimed  at  both  the  specialist  and  the  non-specialist.  The 
Working  Group  sessions  allowed  participants  to  discuss  detailed  technology  and  commercial 
issues  in  depth.  The  Working  Group  Sessions  addressed: 

o  Needs  of  the  Tool  Builders 

o  Needs  of  the  Platform  Suppliers 

o  Needs  of  the  Environment  Suppliers 

o  Needs  of  the  Environment  Users 
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The  results  of  the  PCIS  Workshops  are  two  documents,  the  Interface  Technology  Analysis  (ITA) 
document  and  the  Draft  International  Requirements  and  Design  Criteria  (II^C)  document.  The 
ITA  is  the  proceedings  of  both  rciS  workshops. 

The  IRAC  capiures  the  needs  of  those  groups  mentioned  above.  When  completed,  the 
IRAC  will  represent  a  set  of  requirements  for  military  and  civil  technical  and  programmatic 
requirements  with  accompanying  rationale.  It  is  denoted  International  to  reflect  the  fact  that 
PCIS  is  planned  to  be  an  international  standard  encompassing  international  requirements.  The 
intent  is  to  solicit  comments  from  the  public  on  the  IRAC  from  tool  builders,  platfonn  suppliers, 
environments  suppliers  and  environment  users.  Input  from  organizations  such  as  ADPESO, 
AIAA,  CBEMA,  ECMA,  IEEE,  lEPG,  IWCASE,  NGCR,  NIST,  SIGAda,  and  STARS/DARPA 
is  also  very  welcome.  A  key  to  the  success  of  the  PCIS  Programme  is  to  accurately  reflect  the 
interface  requirements  from  all  segments  of  integrated  software  engineering  environments 
communities. 


THE  NIST  ISEE  WORKSHOPS 


The  goal  of  the  NIST  ISEE  program  is  to  identify  and  establish  a  consensus  for  U.S. 
Federal  government  and  industry  to  take  in  addressing  the  need  for  open  system  ISEE  and 
software  tools  interface  standards.  Today,  software  engineering  environments  come  in  many 
shapes  and  sizes.  They  consist  of  a  variety  of  tools  and  techniques  which  assist  the  software 
developer.  Unfortunately,  there  are  inherent  problems  in  such  environments: 

1)  there  are  approximately  249  existing  activities  identified  that  affect  CASE  tools; 

2)  many  of  these  solutions  are  proprietary: 

3)  most  of  them  do  not  support  the  entire  life-cycle; 

4)  there  is  no  consensus  on  a  reference  model  or  on  standard  interfaces  which  define 
how  these  essential  elements  of  information  can  be  shared  either  by  the  tools  in 
an  environment,  or  by  tools  across  different  software  engineering  environment 
boundaries;  and 

5)  it  is  necessary  that  NIST  serves  as  a  "clearinghouse"  for  coordinating  the  efforts 
of  key  organizations  on  the  establishment  of  a  standardized  ISEE,  and  acts  as  a 
neutr^  forum  for  discussion  of  these  efforts.  This  will  help  reduce  the  duplication 
of  efforts  and  redundant  initiatives,  and  establish  synergism  between  the 
participating  groups. 

The  current  NIST  work  on  software  engineering  environment  issues  centers  on  Workshops 
on  Integrated  Software  Engineering  Environments  (ISEE). 

The  objective  of  these  workshops  is  to  identify  the  coordination  needed  among  key 
working  group  and  relevant  standards  activities  by: 

1)  identifying  and  exploring  fundamental  problems  and  issues  in  ISEE  areas; 

2)  identifying  a  needed  set  of  standards  which  define  a  comprehensive  interface  for 
integrating  software  tools,  and  developing  guidelines  on  interface  standards  for  an 
ISEE. 

The  goal  is  to  provide  guidance  to  Federal  agencies  in  acquiring  an  ISEE.  A  series  of  workshops 
has  been  held  over  the  last  two  years  and  a  Workshop  Working  Draft  was  prepared  and  published 
for  tracking  the  progress  ma^  by  each  meeting.  At  present,  a  core  of  individuals  from 
government,  industry,  and  academia  of  the  NIST  ISEE  Working  Group,  have  committed  to 
developing  a  NIST  ISEE  Reference  Model  Technical  Report.  The  current  NIST  ISEE  Reference 
Model  derines  the  "concept"  of  an  ISEE  in  terms  of  services  and  dimensions.  Most  of  the  items 
which  are  defined  originated,  for  the  most  part,  in  the  ECMA  Technical  Report  -  "A  Reference 
Model  for  Computer  Assisted  Software  Engineering  Environment  Frameworks"  which  was 
approved  by  ECI^  TC33,  September  1990.  However,  some  of  the  definitions  have  been  created 
by  the  NIST  ISEE  Working  Group  through  its  extension  and  modifications  to  the  ECMA 
Reference  Model  Document  in  the  third  and  fourth  ISEE  Workshops. 
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The  NIST  ISEE  Woricing  Group  had  conducted  the  first  NIST  ISEE  Reference  Model 
Mapping  Meeting  at  MCC  in  Austin,  TX  in  March,  1991.  Five  existing  Software  Engineering 
Environment  firamewoiks  were  selected  and  mapped  into  the  developing  NIST/ECMA  ISEE 
Reference  Model  in  order  to  determine  the  adequacy  and  completeness  of  the  NIST/ECMA  ISEE 
Reference  Model.  The  summary  of  this  mapping  effort  will  be  discussed  in  this  workshop.  This 
workshop  will  mainly  focus  on: 

1)  enhancing  the  NIST  ECMA  Reference  Model  Technical  Report; 

2)  reviewing  the  results  of  the  NIST  ECMA  Reference  Model  mapping  exercise;  and 

3)  identifying  and  defining  the  services  related  to  integration. 

NIST  is  planning  to  publish  the  "ISEE  Reference  Model  Technical  Report",  version  1.0  as  well 
as  the  "Report  on  Summary  of  Results  of  the  first  NIST  ISEE  Reference  Model  Mapping"  by  the 
end  of  September  or  early  October,  1991.  Finally,  future  ISEE  Workshops  and  directions  will 
also  be  discussed.  NIST  will  continue  the  harmonization  of  joint  efforts  with  ECMA  TC33  to 
develop  a  standard  ISEE  for  open  system  environments  and  will  continue  the  effort  of  working 
towards  a  full  ISEE  development. 
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THE  IWCASE  WORKSHOPS 


IWCASE  provides  a  forum  for  the  update  of  standardization  activities  through  the 
IWCASE  CASE  standards  coordination  information  exchange.  The  status  of  each  standardization 
activity  represented  was  presented. 

Following  the  IWCASE  information  exchange,  selected  technologies  were  presented  in 
technical  detail  as  PCIS  Emerging  Technology.  The  intent  of  the  Emerging  Technology  session 
was  to  present  emerging  interface  technology  that  potentially  will  support  production  quality 
environments  wi  hin  the  next  five  years. 
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Final  Agenda 

NIST  ISEE  /  PCIS  /  IWCASE  Workshop 
3-7  June  1991 

Hosts:  TRW  and  Los  Angeles  SIGAda 

Sponsors;  U.S.  Department  of  Commerce 

National  Institute  of  Standards  and  Technology  (NIST) 

U.S.  Department  of  Defense 

The  Ada  Joint  Program  Office  (AJPO) 

International  Workshop  on  CASE  (IWCASE) 

Special  Working  Group  (SWG) 

on  Ada  Programming  Support  Environment  (APSE) 

All  are  invited  to  participate  in  all  three  workshops. 


5th  NIST  ISEE  Workshop 
Objectives; 

o  Enhance  the  NIST/ECMA 
Reference  Model 
document. 

-  Review  and  rewrite  new 
services. 

-  Identify  and  define  the 
services  related  to  integration. 

o  Review  the  results  of  the 
mapping  exercise, 
o  Support  the  PCIS  and 
IWCASE  activities. 


2nd  PCIS  Workshop 
Objectives; 

o  Identify  and  establish  the 
scope  of  the  requirements 
for  PCIS. 

o  Assess  the  requirements  of 
emerging  technologies  over 
the  next  five  years, 
o  Examine  a  range  of 
candidate  services  to  serve 
as  the  basis  for  PCIS 
requirements, 
o  Examine  a  range  of 
candidate  technologies  that 
should  be  leveraged  by 
PCIS. 

0  Support  the  NIST  ISEE  and 
IWCASE  activities. 


June  6 

Objectives: 

o  Update  standardization 
working  groups  with  status 
of  other  working  group 
progress. 

0  Identify  overlapping  issues 
and  facilitate  coordination 
on  these  issues, 
o  Support  the  PCIS  and  NIST 
ISEE  activities. 


Results; 

o  Revised  Reference  Model 
document. 


Results; 

o  Updated  version  of 
International  Requirements 
and  Design  Oiteria 
(IRAC). 

o  Updated  version  of 
Interface  Technology 
Analysis  (ITA). 


Results: 

o  Up<lated  status  of 
staiidardi:sation  activities. 


NIST  ISEE /PCIS  /  IWCASJE 
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MONDAY,  3  June  1991 


1 1  :Q0  •  1 3:30  Registration 

13:30  -  15:00  NIST  8c  PCIS  Overview  of  Activities 

General  Welcome  by  Host  and  Chairman 
Overview  of  the  NIST  ISEE  Program  -  Bill  Wong 
PCIS  Programme  Overview  >  Dr.  John  Solomond 
Review  of  First  PCIS  Workshop  -  John  Dawes 
15:00-15:15  Break 

15:15  - 18:00  NIST/ECMA  Reference  Model  -  Dr.  Anthony  Earl 

The  NIST/ECMA  Reference  Model  will  be  presented  as  a  tutorial  in  order  to  serve  as 
a  frame  of  reference  for  NIST  ISEE  and  PCIS  activities. 

18:00  Reception 


NIST  ISEE  /  PCIS  /  IWCASE  - 
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TUESDAY,  4  June  1991 


8:00  -  8:30  Registration 

8:30  •  9:00  General  Welcome  -  Lolo  Penedo 

NIST  ISEE  Workshop  Introductory  Remarks  -  Bill  Wong 
ECMA  Organization  •  Hugh  Davis 
NGCR  -  PSESWG  -  Tricia  Obemdorf 

9:00  •  12:00  NIST  ISEE  Reference  Model  Mapping  Exercise  Summary 

The  mapping  exercise  is  to  validate  the  NIST/ECMA  Reference  Model.  To  validate 
the  model,  S  interface  technologies  have  been  mapped  to  the  model.  These 
technologies  are: 


CAISA,  PCTE,  CIS,  SLCSE,  and  AD/Cycle. 


12:00-  13:30  Lunch 

13:30  -  17:30  Parallel  Tracks  for  NIST  ISEE  and  PCIS 


Track  1:  PCIS  Needs  -  A  Focus  on  N(»is  of  th( 
Caught  in  a  Mine  Field 

Needs  of  Air  Force 
Needs  of  SDI 

Needs  of  ECMA 

Needs  of  Manufacturers 
Needs  of  Platform  Suppliers 

Needs  of  Industry 
Needs  of  Industry 

A  summary  of  each  presentr.tion  will  i 
NIST  ISEE  Working  Group  Sessions. 

Track  2:  NIST  ISEE  Working  Group  Sessions: 


Environment  User 

Dave  Robinson  (SD  SCICON) 
for  Mark  Gibbons  (BT) 

Bob  Hanrahan  (U.S.  Air  Force) 
Jackie  Christina  (U.S.  Army) 

Hugh  Davis  OCX) 

Claude  Baudoin  (SEMATECH) 
Burt  Rubenstein  (Bull) 

Leigh  Power  (MCC) 

Tim  Shorrock  (British  Aerospace) 
&  Dave  Robinson  (SD  SCICON) 

e  made  available  to  those  participating  in  the 


1  Object  Management 

2  Process  &  Ta*’.k  Management 

3  Interface  &  Platform  Services 

4  User  Interfacs 


Lolo  Penedo 
Hal  Hart 

Patricia  Obemdorf 
Bob  Bagwill 


These  sessions  are  intend)  xi  to  review  and  rewrite  new  services  to  enhance  the 
NIST/ECMA  Reference  liodel.  Discussions  will  focus  on  new  services  as  a  result  of 
the  mapping  activity.  PC'IS  Participants  are  encouraged  to  support  this  NIST  ISEE 
activi^  as  it  will  provide  important  input  into  the  PCIS  Needs  Working  Groups, 
especially  for  the  Needs  of  the  Tool  Builder,  Needs  of  the  Environment  Supplier,  and 
the  Needs  of  the  Platforai  Supplier. 


N/ST  ISEE  /  PCIS  /  IWCASE 
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WEDNESDAY,  5  June  1991 


8:30  -  12:00  Parallel  Tracks  for  NIST  ISEE  and  PCIS 
Track  1 :  PCIS  Working  Group  Sessions: 

1  Needs  of  the  Tool  Builders 

Chairman:  Herman  Fischer  Co-Chairman:  Dr.  Hans  Keus 

2  Needs  of  the  Platform  Suppliers 

Chairman:  Bob  Munck  Co-Chairman:  G6rard  Memmi 

3  Needs  of  the  Environment  Suppliers 

Chairman:  Geoff  Clow  Co-Chairman:  Regis  Minot 

4  Needs  of  the  Environment  Users 

Chairman:  Dr.  Tim  Lindquist  Co-Chairman:  Dr.  Vic  Stenning 
Track  2:  8:30  -  10:45  Continuation  of  NIST  ISEE  Working  Sessions  from  Tuesday. 

1 1:00  -  12:00  NIST/ISEE  Plenary  (Summary  of  NIST/ISEE  Working  Groups) 

12:00  -  13:30  Lunch 

1 3:30  -  17:30  Parallel  Tracks  for  NIST  ISEE  and  PCIS 

Track  1 :  Continuation  of  PCIS  Working  Group  Sessions  from  Morning 

Track  2:  NIST  ISEE  Plenary 

13:30-  16:30  Integration  Services 

The  ECMA  Reference  Model  does  not  completely  address  integradon  as  a  separate 
service  but  as  acdvides  of  other  services.  Consequently,  there  are  some  integradon 
specific  services  that  are  not  idendfied  in  the  ECMA  Reference  Model.  Hie  purpose  of 
this  session  is  to  address  these  integration  services. 

16:30  -  17:30  ISEE  Working  Group  Closing  Remaiics 

This  is  the  final  session  of  the  NIST  ISEE  Workshop.  It  includes  a  wrap-up  of  the 
ISEE  WG  acdvides  and  will  address  future  workshop  direcdon. 

Note:  The  local  chapter  of  ACM  will  be  hosting  a  dinner  presentation  with  Teri 
Payton  speaking  on  national  reuse  initiatives.  Please  register  by  17:00  Monday. 

18:(X}  Cocktails  &  Social  Hour 
19:(X)  Buffet  Dinner 
20:00  Program 

- NIST  ISEE  /  PCIS  /  IWCASE  - 
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THURSDAY,  6  June  1991 


8:00  >  8:30  Registration 

8:30  •  12:00  IWCASI  CASE  Information  Exchange  &  PCIS  Emerging  Technology 


IWCASE  will  provide  an  update  of  standardization  activities  through  the  IWCASE 
CASE  standards  coordination  information  exchange.  Dave  Sharon  will  chair  the 
morning  session.  The  status  of  each  standardization  activity  represented  will  be 
presented. 


IWCASE  Standard  Update  Reports 

CALS  &  PDES 

CDIF 

IEEE  PI  175 
ECMA  PCTE 
ATIS 

Needs  of  the  Navy  NGCR  PSESWG 


Dave  Sharon  (Chairman) 

Tom  Baker  (Boeing) 

Richard  Good 
Dave  Sharon  (CASE) 

Hugh  Davis  (ICL) 

Eric  Black  (Atherton) 

Patricia  Obemdorf  (U.S.  Navy) 


Following  the  IWCASE  Information  Exchange,  selected  technologies  will  be 
presented  in  technical  detail  as  PCIS  Emerging  Technology.  The  intent  of  the 
Emerging  Technology  Session  is  to  present  emerging  intettace  technology  that 
potentially  will  support  production  ^ality  environments  within  the  next  S  years. 
Information  Exchange  &  Emerging  Technology  Presentations  include: 


IEEE  PI  175  Dave  Sharon  (CASE) 

CALS  &  PDES  Tom  Baker  (Boeing) 


Certain  technologies  were  presented  at  the  First  PCIS  Workshop  and  will  not  be  repeated 
here.  These  include  CAIS-A,  CDEF,  CFI,  and  ECMA  PCTE. 


12:00-  13:30  Lunch 


13:30  -  17:30  Parallel  1  racks  for  Technology  Plenary  and  PCIS  Working  Groups 

Track  1 :  Continuation  of  Information  Exchange  &  Emerging  Technology  Sessions  from  Morning 

ATIS  and  CIS  Eric  Black  (Athenon) 

COHESION  Ed  Cuoco  (DEC) 

AD/Cycle  _  Bob  Ekman  (IBM) 

Adding  Control  Intention  to  PCTE  Dr.  Huw  Oliver  (HP) 

Module  Interconnection  and 

Reacdve  Integration  Dr.  Robert  Balzer  (USC-ISI) 

IRDS  Dr.  James  Emerson  (RTI) 

(unable  to  attend  -  slides  in  proceedings) 

Track  2:  PCIS  Working  Group  Sessions  -  WG  Sessions  of  Wednesday  afternoon  vkdll  continue. 
Some  WGs  may  want  to  participate  in  the  in  the  Emerging  Technology  Session. 

FRIDAY,  7  June  1991 


9:(X)  - 12:00  Introduction  -  Gary  Pritchett 

Short  Piesentadon  by  Session  Chaiimen  followed  by  general  discussion 
Closing  Address  -  Gary  Pritchett 
Closing  Remarks  -  Currie  Colket 


NIST  ISEE  /  PCIS  /  IWCASE 
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Chairman’s  Opening  Remarks  for  2nd  PCIS  Workshop 

Mr.  Gary  Pritchett,  US  PCIS  Expert  Team  Leader 

Welcome  all  to  the  2nd  PCIS  Requirements  Workshop. 

I’m  pleased  that  this  workshop  is  being  held  in  conjunction  with  the  5th  NIST  ISEE 
Workshop  and  the  IWCASE  Workshop.  TTie  activities  of  these  workshops  are  very  imponant 
and  complementary  to  the  PCIS  program.  For  example,  the  reference  model  work  being  done 
at  the  NIST  workshop  is  relevant  to  the  PCIS  program,  complementary  i'l  that  it  identifies  a 
superset  of  the  services  likely  to  be  provided  in  a  PCIS  environment  framework  and  provides  a 
context  in  which  to  compare  several  existing  or  emerging  systems  of  interest  to  the  PCIS 
program.  A  rather  full  week  of  technical  presentations  and  working  group  sessions  is  planned. 
I  encourage  you  to  support  as  many  sessions  as  you  can  and  expect  this  to  be  a  very  productive 
and  informative  workshop. 

This  is  the  2nd  of  two  workshops  to  validate  requirements  for  the  PCIS  program.  The 
primary  goals  of  the  requirements  validation  phase  is  to  gather  requirements  from  the  SEE 
community,  validate  requirements  defined  in  the  NRAC,  survey  available  or  emerging 
technologies,  produce  an  IRAC  and  ITA,  and  propose  a  way  forward  the  PCIS  program  to  the 
NATO  Special  Working  Group  on  APSE  which  is  the  PCIS  programme’s  sponsoring 
organizadon. 

The  requirements  workshops  are  being  held  to  suppon  the  requirements  validation  phase. 

In  support  of  the  requirements  validation,  we  have  planned  several  technical  presentations 
on  the  needs  of  various  programmes  or  organizations.  The  requirements  input  is  being  gathered 
in  the  four  parallel  woiiting  sessions  held  during  the  workshop.  There  requirements  are  being 
discussed  from  the  following  points  of  view; 

•  Needs  of  the  environment  user 

•  Needs  of  the  tool  builder 

•  Needs  of  the  environment  supplier 

•  Needs  of  the  platform  supplier. 

The  input  captured  at  these  sessions  will  be  the  basis  for  producing  the  IRAC. 

Presentations  are  being  made  to  the  entire  workshop  on  available  or  emerging 
technologies.  These  presentations  will  provide  input  to  the  ITA. 

The  first  workshop,  held  in  London  during  29  April  through  3  May,  had  a  similar  format 
as  this  workshop.  That  workshop  was  planned  and  conducted  by  a  European  team  headed  by 
Wing  Ctnmdr.  Dennis  Longdon.  They  did  an  excellent  job  and  the  workshop  was  a  huge 
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success.  That  workshop  produced  initial  requirements  input  for  the  IRAC  and  good  presentations 
were  made  on  available  and  emerging  technologies. 

I'he  tasks  for  this  workshop  are  to:  (1)  conduct  a  quick  review  of  the  results  of  the  first 
workshop,  then  capture  any  important  additional  requirements  issues  so  the  requirements 
validation  can  be  completed  and  ^e  IRAC  can  be  produced  and  (2)  collect  additional  input  on 
emerging  technologies  as  input  for  the  Fl'A. 

After  the  workshop  is  complete,  a  team  of  experts,  selected  from  the  SEE  community  in 
Europe  and  North  America,  will  analyze  the  input  received  at  the  workshops,  reconcile 
inconsistencies,  wordsmith,  and  produce  the  final  versions  of  the  IRAC  and  ITA. 

I  strongly  urge  you  to  participate  in  the  working  sessions  and  voice  any  issues  you  feel 
are  important  for  requirements  consideration.  The  issues  recorded  during  these  sessions  will  form 
the  basis  for  the  experts  preparation  of  the  PCIS  requirements  document.  Voicing  your  concerns 
is  the  best  way  to  influence  the  PCIS  requirements  and  programme. 
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NIST/NCSL  Initiatives 


*  Many  existing  disjointed  activities 

-  249  standards  activities  identified 
affecting  CASE  tools 

*  Many  solutions  are  proprietary 

*  Few  activities  attempt  to  address 
the  entire  software  lifecycle 

*  No  consensus  on  a  reference  model  or 
standard  interfaces 

*  Need  neutral  forum  for  discussion 

*  ISEE  Workshops 

FOCUS  ON: 

-  NIST/ISEE  Reference  Model, 

-  User  Interface, 

-  Process  and  Task  management, 

-  Ojective  management  and  Repository, 

-  Interface  and  platform  services, 

-  RM  Mapping  Guidelines, 

-  ISEE  Glossary  Definition,  and 

-  Evaluation  of  existing  technologies 
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ECMA 


NIST  ISEE  WG  Charter: 


eral  agencies  in  acquiring  on  ISEE 


NIST  ISEE  Workshop 

Chair:  William  Wong,  NIST 
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ISEE  Workshops  Participants: 


-  Federal  Agencies: 

NIST,  US  AirForce,  US  Army,  US  Navy,  DARP A/STARS, 
AJPO/PCIS,  IRS,  fflS,  US  Senate.  VA,  NASA,  NSF, 

US  Coast  Guard,  USDA,  HHS,  USDT,  GSA,  CAIS-A, 

NIST/APP,  SLCSE,  NSA,  IDA,  USAF/STSC,  USN/PSESWG 

"  Industries: 

IBM.  HP,  SUN,  TRW,  Mitre,  RockweU,  MCC,  SPC.  IEEE, 

UNISYS,  DEC,  IDE,  Teledyne  Brown,  Intemietrics,  ATAC, 

General  Research  Coip,  Abacus  Technology,  CADRE,  I-logic, 
Honeywell,  Boeing  Aerospace,  Geodymanics,  Texas  Instruments, 
AVTEC,  Marie  V.  Systems,  MKL  Software,  EDPNS,  SPS,  AD/Cycle, 
PI  175,  CDEF,  PDES,  IRDS,  Charles  Draper  Lab,  QMS,  CIS,  ATIS, 
Integrated  Systems,  Softran,  Emerging  Technologies  Group, 

UNIX  Adviser,  ATT,  IWCASE,  OODBTG,  AIAA,  SoftTech 

-  Academia: 

U  of  Maryland,  SEI,  U  of  Houston,  Jersey  City  State  College, 
Georgetown  U,  U  of  VA,  Johns  Hopkins  U,  New  Jersey  Institute 
of  Technology,  George  Mason  U. 

-  International 

NEC/Japan,  Hitachi/Iapan,  IP  A/Japan,  Netron/Canada,  SPP/Brazil, 
STLAJK,  HP/UK,  ECMAyTC33.  Colin  TuUy  Associatea/UK,  ECMA, 
ni/Taiwan,  Hong  Kong  Polytechnic/Hong  Kong,  PCTE,  SIGMA/Japan 
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FIRST  NIST  ISEE  Workshop 
SUMMARY 

-  Hosted  and  Sponsored  By  NIST, 

May  25,  1989 

*  Open  Architecture  Approach 

*  Strawman  Requirements 

*  Reference  Model 

*  Taxonomy  and  classiflaition  of 
tools  and  services 

*  Interfaces  for  environment  services 

*  Information  Interface  Language 

*  Services/properties  provideci  by  an  ISEE 

*  An  assessment  process  to  determine  how 
close  we  are  to  complete  environment 

*  coordination  of  related  ISEE  groups  and 
activities 

-  Workshop  Product 

*  Workshop  Working  Draft, 

July,  1989 


20 


SECOND  NIST  ISEE  \vorkshop 
SUMMARY 

*  Hosted  By  Teledyne  Brown 

Engineering  and  sponsored  by 
NIST,  Dec  5-6,  1989 

**  Ideittifled  and  deflned  of  an 
ISEE  Reference  Model 

*  Conducted  a  NIST  ISEE  Reference  Model  survey 

*  Ide  ntified  and  defined  a  set  of  ISEE  end-user 
re(|,uirements 

*  Established  synergism  between  the  users,  vendors 
and  standards  groups 

*  Promotion  of  convergence  of  ISEE  standards  and 
interfaces 

-  Workshop  Product 

*  Workshop  Working  Draft, 

May,  1990 
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THIRD  NIST  ISEE  Workshop 
SUMMARY 

.  Hosted  By  US  NAVY  and 
Sponsored  by  NIST, 

May  31  -  June  1,  1990 

*  Reviewed  Reference  Models 

*  User  Interface 

*  Process  and  Task  Management 

*  Object  Management  and  Repository 

*  Summary  of  the  ISEE  Survey 

*  Selected  the  ECMA  RM  as  the  base 
definition  for  the  development 

of  the  NIST  ISEE  RM  Document 

«  Reviewed  the  ECMA  RM  Version  3.0 
(ECMA/TC33/TGRM/90/011 , 

May  25,  90) 

*  Established  a  collaborative  effort 

with  ECMA/TC33  to  develop  a  standardized 
ISEE  RM  Techical  Report 

*  Workshop  Products 

Comments  on  the  Version  3.0  of  tha  ECMA 
Reference  Model,  Version  1,  August,  1990 

*  Workshop  Working  Draft, 

September,  1990 
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FOURTH  NIST  ISEE  Workshop 
SUMMARY 

-  Hosted  By  IBM  and 

Sponsored  by  NIST, 

October  11-12,  1990 

*  User  Interface 

*  Process  and  Task  Management 

*  Object  Management  and  Repository 

*  Interface  and  Platform  (Integration) 

*  RM  Mapping  Guidelines 

*  RM  Selection  Guidelines 

.  ECMA  PCTE,  CAIS-A,  CIS, 

SLCSE,  AD/Cycle 

*  RM  Mapping  Meeting 
-  hosted  by  MCC, 

March  12-13,  1990 

-  Workshop  Products 

*  Summary  of  the  4th  ISEE 
Workshop,  October,  1990 

*  NIST  ISEE  RM  Subset  for 

Mapping,  February,  1991 

*  NIST  ISEE  RM  Mapping 

Guidelines,  Version  1.2 
March,  1991 
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FIFTH  NIST  ISEE  Workshop 
SUMMARY 

-  Hosted  By  TRW  and  Los  Angeles  SIGAda, 
sponsored  by  NIST,  AJPO,  IWCASE,  and 
SWG  on  APSE,  June  3-5,  1991 

*  Enhance  the  NIST/ECMA  Reference  Model 
Technical  Report 

*  Review  the  results  of  RM  mapping  exercise 

*  Identify  and  define  the  services  related  to 
integration 

-  Workshop  Products 

*  NIST  ISEE  Reference  Model  Technical  Report, 
Version  1.0  (Target  date:  Sept.  30,  1991) 

*  Summary  of  results  of  the  1st  NIST  RM 
Mapping  Report  (Target  date:  Sept.  27, 1991) 
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Future  Workshops  and  Directions 

6th  Workshop  will  be  hosted  and 
sponsored  by  NIST,  October  ?, 

1991  in  Gaithersburg,  MD 

7th  Workshop  will  be  hosted  by 
SEX.  and  sponsored  by  NIST,  May 
?,  1992,  in  Pittsburgh,  Penn 

8th  Workshop  will  be  hosted  and 
sponsored  by  NIST,  October  ?, 

1992  in  Gaithersburg,  MD 

9th.  Workshop  will  be  hosted  by 
STSC/T7SAF  emd  sponsored  by  NIST, 
May  ?,  1992? 

Harmonize  the  joint  effort  with 
ECMA/TC33  to  develop  a 
standards  ISEE  for  Open  System 
Environments 

NIST  ISEE  effort  is  working 
towards  an  (full)  ISEE 
development 
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Importance  of  Interface  Technology 
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NIST’s  Preliminary  Reference  Model 
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Approximately  $50  million  combine 
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rte  CAIS-A  and  PCTE+  sponsors  cooperating 


Histor 


Recommendation:  Convergence  technically  feasible  resulting  i 

evolutionaiy  interface  standard. 
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New  interface  specification  to  be  available  in  mid-1994 


PCIS 


Common  APSE  Biterface  Set 


PCIS  Programme  Established  - 
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Civil  organizations  encouraged  to  become  actively  involved 


•  • 
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PCBUSLp^  B 


PCIS  North  American  Expert  Team 
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European  PCIS  Expert  Team 
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Expert  Consultants: 

Qaude  MAUPETIT  CR2A 

Gerard  BOUDIER  GIE  EMERAUDE 

Dick  FIKKERT  FEL-TNO 


ECMA  TC33  Participation 


CO 

c 

o 

i 

CO 


c 

o 


2 


CA 

g 

> 

2 

ia 


^  •S 

o  g 

c  o 

o  -s 

*5  c« 

5  c  ^ 

S  ‘2  S' 

o  2  2 
O  g  2 

’S  ^ 

-2  *3  •« 

a  «  ^ 

.£  2  c« 

O  *2  -C2 

-S  g 

o  B 

•S « ■§ 
.1,  g  «s 
S  (5*^ 


u 

CO 

s 
o 

p  . 

CO 

U4 

I 

g 


c 


2 


c 

i 

> 

o 

> 

G 

c« 

•» 

*C 

c 


o. 

I 

I 

G. 

< 

u 

P 


G  (G 


2 

tx 

*2 

o 

'W 

G 

sa 

G 

O 


2 

B 

O 

4-» 

X 

a> 


I 

E 

.B 

s 


P  > 


O 

c/3 


^  ITS  O  j^rv 

S  ^  ^  e 
O  'C 


X 

£ 


CO 


V 

I 

£  w> 

‘p  G 


a 

X  ^ 
«  8 


^  *s 


M) 


cn  CO 
cn  CO 


CO 

CO 

U 

H 


42 


FCBUS;p«el6 


Interface  Evolution 


FCKUS^P(Bc17 


STARS  Participation 
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Potential  Impact  to  all  previous  planning  activities 


SWG  on  APSE  [11-12  Dec  1990] 
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3-5  December  SWG  #27  for  Continuation  Decision 


Summary 
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PCiS  must  be  a  viable  commercial  standard  that  satisfies 
requirements. 


PCIS  Requirements  Validation 
First  Workshop 
Heathrow  Park  Hotel,  UK 


29/4/91 


3/5/91 
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PCIS  Requirements  Validation  First  Workshop 


Objectives: 

•  Start  to  establish 
requirements  (IRAC) 

•  Start  to  establish  candidate 
technologies  (ITA) 

Processes  to  be  continued  at 
Second  Workshop 


PClS  Requirements  Validation  First  Workshop 

Outputs: 

•  Workshop  Proceedings 

Precis  of  plenary  sessions 
Sent  to  all  attenders 

•  Workshop  Report 

Protodraft  IRAC  and  ITA 
Input  to  Second  Workshop 
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PCIS  Requirements  Validation  First  Workshop 

Timetable: 

Monday  p.m.  General  Introduction 

Tuesday  a.m.  Needs  of  PCIS 

Tuesday  p.m.  Emerging  Technologies 

Wednesday/Thursday  Parallel  Sessions: 
Platform  Suppliers  (P) 

Environment  Suppliers  (E) 

Tool  Suppliers  (T) 

Environment  Users  (U) 

Friday  a.m.  Concluding  Session 
Parallel  session  reports 
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PCIS  Requirements  Validation  First  Workshop 
Wednesday/Thursday:  Tool  Suppliers 

•  Comprehensive  PTI 

•  Integration:  data,  control,  presentation 

•  Query  language 

•  Tool  intercommunication 

•  Tool  registration 

•  Object  orientation 

•  Interoperability 

•  Distribution  costs 

•  Heip  services 
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PCIS  Requirements  Validation  First  Workshop 

Wednesday/Thursday:  Environment 
Suppliers 

•  Environments  and  Frameworks 

•  Multipart  structure  and  conformity 

•  Support  for  long  lifetimes  and  reuse 

•  Formal  and  informal  definitions 

•  Object  orientation  (more  or  less) 

•  Query  language 

•  Preservation  of  investment,  foreign  tools 
and  data 
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PClS  Requirements  Validation  First  Workshop 

Monday  afternoon:  General  Introduction 


PCIS  Programme 
STARS  Programme 
lEPG  TA13  Programme 
PIMB 


J.Solomond 

R.Munck 

B.GIadman 

F.Sall6 
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PCIS  Requirements  Validation  First  Workshop 


Tuesday  morning:  The  Needs  of  PCIS 

Tool  Suppliers  J.-P.  Bourguignon 

(SFGL) 

Platform  Suppliers  G.Sagols  (IBM) 

C£C  Ibc't 

Environment  Suppliers  R. Minot 

(GIE  Emeraude) 

Environment  Users  T.Shorrock  & 

J.Thornley  (BAe) 
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PCIS  Requirements:  Validation  First  Workshop 

Tuesday  afternoon:  Emerging  Technologies 


Opening  Address: 

J.Derniame 

Caught  in  a  Minefield 

M.Giibbons  (BT) 

ATIS 

A.Argento 

OSF 

H.-J.  Jeanrond 

CFI 

T.Rhyne 

CDIF 

H. Barlow 

ECMA  PCTE 

M.Morron 

PCTE+ 

B.Basdell 

CAIS-A 


G. Pritchett 


PCIS  Requirements  Validation  First  Workshop 

Wednesday/Thursday:  Platform  Suppliers 

•  Small  group,  useful  discussiort,  no  special 
focus 

•  Scalability,  implementability 

•  Security 

•  Validation 

•  Education  and  Training 

•  Internationalization 

•  Public  Domain 
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PCiS  Raquiremdnts  Validation  First  Workshop 

Wednesday/Thursday:  Environment  Users  1 

•  CM  and  PM  including  measurement  and 
traceability 

•  Integration  and  scalability 

•  Openness 

•  Multiplatform,  multilanguage, 
multimethod 

•  Support  for  evolution 

•  Support  for  commercial  development 
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PCIS  Requirements  Validation  First  Workshop 

Wednesday/Thursday:  Environment  Users  2 


Adopiion  of  new  fechnology  io  improve 
quality  and  productivity  Is  a  major 
challenge  for  any  organisation 


Requires  partnership  between  suppliers, 
users,  and  standards  groups  to  implement 
the  change  process: 

•  justification  (cost/beriefit) 

•  initiation  (incremental,  organised) 

•  management  (commitment,  fccus) 
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PCIS  Requirements  Validation  First  Workshop 
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Results:  Generate  a  revised  Reference  Model  document  to  be  published  late  summer. 
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User  Interface  -  B.  Bagwill 


Arcadia  NIST/ISEE  Agenda  -  Wednesday,  June  5 
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Chairman’s  Closing  Remarks  for  the  Second  PCIS  Workshop 
Mr.  Gary  Pritchett 

General  Thanks 

Thanks  to  the  Chair  and  co^hair  people  for  conducting  valuable  Working  Sessions. 

Thanks  to  the  Presenters  for  giving  us  insights  into  their  activities;  these  will  prove  to  be 
useful  to  the  PCIS  Programme. 

Thanks  to  the  Participants  in  the  workshop;  without  you  it  would  not  have  been  a  valuable 

event. 


Special  Thanks 

Thanks  to  Dr.  John  Solomond  and  the  AJPO  for  sponsoring  the  meeting  on  behalf  of  the 
NATO  Special  Working  Group  on  APSE. 

Thanks  to  Hal  Hart  and  everyone  at  TRW  for  hosting  the  meeting. 

Thanks  to  Currie  Colket  for  all  the  energy  he  put  into  organizing  the  PCIS  Workshop  and 
lining  up  speakers. 

Thanks  to  Wing  Commander  Dennis  Langdon  and  the  European  Expert  Team  that 
managed  the  London  PCIS  Workshop  as  they  gave  us  a  strong  base  on  which  to  build  at  this 
PQS  Workshop. 


What  Will  Happen  Next 

We’ve  collected  Requirements  and  Neecls  from  Environment  Users,  Environment 
Suppliers,  Tool  Suppliers,  and  Platform  Suppliers. 

We’ve  heard  presentations  on  existing  or  emerging  technologies  relevant  to  the  PCIS 

effort 


Over  the  next  few  mcmths  the  PCIS  Expert  Team  will  analyze  these  inputs  to  produce  the 
IRAC  and  the  ITA  documents. 
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The  IRAC  will  be  produced  by  analyzing  requirements  capntred  at  the  two  PCIS 
workshops  and  in  the  NRAC. 

•  The  Experts  will  be  reconciling  conflicts  as  best  as  possible. 

•  The  Experts  will  be  consolidating  these  inputs  into  o  complete  document. 

The  high  level  structure  of  the  IRAC  document  will  be: 

•  Requirements  of  Environment  Users: 

From  the  point  of  view  and  from  the  level  of  the  Environments  Users, 
there  will  be  requirements  in  the  document  about  the  PCIS  Process,  and 
there  will  be  requirements  on  the  Products  of  the  PCIS  Programme. 

•  Detailed  Requirements: 

These  requirements  will  be  similar  in  structure  to  requirements  in  the 
existing  phlAC. 

•  Required  Services: 

An  identification  of  services  from  the  NIST/ECMA  Reference  Model  that 
are  required  for  PCIS  will  be  located  in  this  section. 

When  completed,  the  IRAC  will  be  circulated  for  a  Public  Review. 

The  ITA  will  be  a  collection  of  Summaries  of  presentations  with  Presentation  Materials. 
When  completed,  it  will  be  publicly  available. 

After  the  Requirements  and  the  ITA  are  complete,  the  Expert  Team  will  formulate  a  way 
forward  (politically,  a  set  of  alternative  ways  forward)  for  PCIS.  These  will  be  presented  to  the 
SWG  for  a  Go/NoGo  decision  on  the  continuation  of  the  PQS  Programme. 

The  challenge  for  the  Experts,  then,  is  to: 

•  Understand  the  inputs  we  have  heard  here,  and 

•  To  craft  a  way  forward  that: 

is  respcMisive  to  what  we  have  heard 

will  produce  a  product  that  is  acceptable  to  the  SWG,  and 
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does  not  invalidate  the  work  and  impottant  progress  made  in  the 
environment  and  PTI  areas  by  existing  programs  so  far. 

The  documents  produced  by  the  effort  of  the  Experts  are  in  the  Public  Domain  and  will 
be  made  available  to  anyone  who  wants  them  when  they  are  completed. 


Chairman’s  Impression  of  the  2nd  Worksho|$ 

As  I  observed  the  different  Working  Group  sessions,  an  interesting  point  made  is  that  the 
level  of  discussion  varied  widely. 

The  Environment  Users  Group  has  already  had  a  significant  impact  on  the  PCIS 
Programme. 

•  The  sponsor  and  the  PCIS  Experts  are  much  more  aware  of  requirements  in  this 
particular  area. 

•  There  is  so  much  awareness  in  this  particular  area  that  sometimes  it  seems  that 
some  people  want  to  listen  to  only  this  aiea. 

Throughout  this  Second  PCIS  Workshop,  a  popular  question  I’ve  heard  is:  "What  is 

PCIS?" 

•  Sometimes  it  was  asked  in  the  context  of  "you  must  tell  me  what  it  is  before  I  can 
tell  you  what  I  need." 

•  Sometimes  it  was  asked  maybe  to  see  if  we’ve  already  decided  what  it  is. 

My  encouragement  to  everyone  is  to  le;  the  answer  to  that  question  emerge  out  of  the 
analyses  of  the  inputs  we’ve  received  sd  far  and  in  the  preparation  of  the  way  forward  that  will 
be  presented  to  the  SWG. 

..  V  V, 
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SECOND  PCIS  WORKSHOP 


SWG  on  APSE  Tasking 

1.  Validate  the  NRAC  and  include  civil  requirements. 

2.  Investigate  what  the  present  technology  in  interface  requirements 
is  providing,  and  assess  the  emerging  technology  over  the  next  5 
years. 

3.  Compare  the  results  of  what  industry  is  providing. 

4.  Analyze  these  differences,  prioritize,  and  cost  the  work. 


QUESTION  FROM 

FIRST  &  SECOND  PCIS  WORKSHOP 


What  is  PCIS? 


BO 


SECOND  PCIS  WORKSHOP 
Results 

1.  Interface  Technology  Assessment  (ITA) 

Contain  presentation  slides  of  PCIS,  NIST  ISEE  &  IWCASE 

Contain  ^  ummaiy  of  PCIS  Presentations 

Distributed  to  attendees  of  Both  PCIS  Workshops  ~  8  July 

2.  International  Requirements  and  Design  Criteria  (Il'^C) 

WiU  capture  Environment  User  Needs 

WiU  capture  Detailed  Technical  Requirements 
Will  capture  Required  Services 

o  Services  in  NIST/ECMA  Reference  Model 
Distribution  to  public  --22  July  with  solicitation  of  comments 
Deadline  for  public  comments  is  4  September 
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SECOND  PCIS  WORKSHOP 
THOUGHTS 


1.  There  should  be  a  greater  emphasis  placed  on  the  needs  of  the 
environment  user.  These  requirements  will  be  captured  in  the 
IRAC  and  used  for  the  PCIS  definition. 

2.  It  is  clear  that  PTI  technology  may  provide  a  viable  alternative  to 
satisfy  the  needs  of  the  environment  user  in  the  near  term.  It  may 
provide  the  best  alternative  to  satisfy  the  needs  of  the 
environment  user  in  the  long  term. 

3.  There  was  excellent  progress  in  updating  the  NR/iC  level 
requirements  of  the  tool  builder  and  suppliers. 

4.  There  are  perceived  and  real  barriers  to  the  use  of  PTI  based 
technology.  The  PCIS  Programme  must  address  these  barriers. 

5.  Tlie  2  PCIS  Workshops  has  provided  the  SWG  on  APSE  with 
extremely  valuable  information. 
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L\  SIGADA  PRESENTATION 

GOALS  AND  STRATEGIES  TOWARDS 
DOMAIN-SPECIFIC  REUSE  BASED  DEVELOPMENT 
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Stages  of  Reuse 


87 


Tiia^e-ptiiased  lim^itutionalization  of  Reuse 
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What  is  needed  to  enable  a  bansition  to 
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WSiat  is  needed  'to  enable  a  move  towards  black-box 
reuse?  (ConL) 
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STARS 
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Whjat  is  needed  to  evolve  reuse  libraries  into 
proactive  software  tM!oi(eraee^<exchanges?  (Cent) 
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is  STAINS  Doing  to  Support  Reuse 
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STMIS 
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STARS  LIBRARY  MECHANISMS/ 
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Recall  software  assets 


VALUE-ADDED  ROLES  OF  ENTREPRENEURS 
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New  development 
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SECTION  I 

NIST  ISEE  WORKSHOP 
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ECMA  =  European  Computer  Manufacturers  Association 


ECMA  TC33  TGRM  POSITION 


0  ECMA  TC33  TGRM  remains  actively  committed 
to  progressing  the  CASEE  RM  work 


0  By  the  September  meeting  of  NiST,  ECMA  TC33 
TGRM  will  provide  ECMA’s  feedback  on  the 
changes  made  to  the  CASEE  RM  to  NiST 


0  ECMA  TC33  TGRM  Is  performing  a  set  of 
mapping  exercises  from  which  to  validate 
tho  CASEE  RM.  These  wiil  be  shared  with  NiST 


MG/STDS/ 
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ECMA  TC33  TGRM 
Organisations  and  Mappings 


Organisations 

0  Eureka  Software  Factory 

0  EAST  Environment 

0  Digital 

OBNR 

0  Sysecs 

OHP 

OBT 

0  University  of  Dortmund 

Mappings 

OESF 

OEAST 

OAHS 

0  Entreprise  2 
0  Softbench . 

Ofc-re 


MG/STDS/ 


115 


ECMA  TC33  TGRM:  -  TIMETABLE 


0  Next  TGRM  Meeting;  26th  June  1991 
•  Heathrow,  London 

.  discuss  NIST  changes  &  status/progress  to 
date  on  mapping  work 


0  Next  TC33  Meeting;  3>4th  September  1991 

•  Nice,  France 

•  invite  NiST  representation 

•  discuss  mapping  results  to  date 

•  review  changes  made,  and  lessons  learned 
with  respect  to  the  CASEE  RM 

•  clarify  publishing  and  labelling  details  to 
ensure  document  consistency 


MG/STDS/ 


The  Navy's 


Next  Generation  Computer  Resources  (NGCR) 


PROJECT  SUPPORT  ENVIRONMENT 

V/ORKING  GROUP 

(PSEWG) 


Trlcia  Oberndorf 


Naval  Air  Development  Center, 
Warminster,  PA 
(215)441-2737 
tr1cia@nadc.nadc.navy.m11 
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APPROACH 


OBJECTIVE:  select  Industry-based  PSE 

Interface  standards  for  use  In 
support  of  Navy  systems 


*  Joint  Industry/Navy  working  group 

-  Navy  co-chairmen  (one  military,  one  civilian) 


*  Subgroups  according  to  needs 

-  Approach/Requirements/Available  Technology 

-  by  Interface  area 


^  Benefit  from/coordinate  with  as  many  other 
related  projects  as  possible  (e.g.,  NIST,  STARS) 


*  Start:  ~  April  1991 


^  Completion:  ~  1 997 
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ISSUES 


^  possible  goals 

-  tool  "mix  &  match" 

-  minimize  training 

-  maximize  ease  of  transition  to  PDSS 

-  maximizing  tool  commonality 

-  host  interchangability 

-  attaining  particular  SEI  assessment  level 

-  compatibility  with  other  NGCR  standards 

*  scope  of  the  PSE 

-  software  only? 

-  Ada  only? 

-  wliat  application  mix? 

*  level/extent  of  standardization 

-  choose  toolset 

-  choose  OS, DBMS,  etc. 

-  standardize  on  interfaces  key  to  the 

PSE  framework 


*  user  interface 
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CAIS-A  (MIL-STD-1838A)  MAPPING 
TO  NIST  REFERENCE  MODEL 


Geoff  Clow 
SofTech,  Inc. 
Clow@NOSC.MIL 


Purpose 
Mapping  Effort 
Guidelines,  NIST  Support 
Benefits  to  Author 
Services 

Service  Omissions 
Service  Incompleteness 

Service  Dimensions 

Dimension  Redundancies 
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PURPOSE 


Assist  Evolution  of  the  RM  and  the  Guidelines. 
Not  to  e.g.  present  CAIS  and/or  the  RM. 


CAIS 

Standard  interface  specification  for: 

Programming  of  sophisticated,  integrated 
project  support  environments. 

Portability  of  projects  (tools,  databases, 
users). 
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MAPPING  EFFORT 


2  Day  kick-off  meeting 

Orientation,  Guidelines,  Practise. 

2  Weeks,  1  person  mapping. 

1  pass,  little  review  and  revision. 

1-2  Weeks  more  for  proper  public  draft 

Intended,  for  revised  RM. 

Mapper  Background 

CAIS  author  and  implementer 

Familiarity  with  subject  system. 

Participant  in  Waltham  and  Winnersh 
CAIS/PCTE  Joint  studies 

Experience  with  similar  exercises  (mapping 
to  an  independent  model). 
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GUIDELINES,  NIST  SUPPORT 


Valuable  kick-off  meeting 

Uncertainties  inevitable 

Number  of  service  areas  and  dimensions, 
Level  of  detail. 

Only  one  example  from  which  to  generalize. 

Critique  of  lab  exercise  was  single  most  helpful 
experience. 

Future  mapping  efforts  would  benefit  from: 

Existence  of  additional  mappings. 

Simulating  lab  experience  in  Guidelines 

Examples  (correct  and  less  correct)  with 
critique; 

Stress  information  partitioning  and 
standard  characterizations,  where  possible 
(provides,  supports,  available, 
unavailable). 
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BENEFITS  TO  AUTHOR 


Identify  incompleteness  and  redundancy  in  a  system 
or  its  documentation. 

Identify  redundancy,  alternatives  and  complements 
between  multiple  systems. 

Analogous  comparison  exercises: 

Framework  vs  Requirements 

e.g.  CAIS,  PCTE  vs  RAC,  NRAC,  EURAC 

Framework  vs  Framework 

e.g.  CAIS  vs  PCTE  in  Waltham,  Winnersh 

Framework  vs  Reference  Model 

e.g.  Mappings  to  ECMA  &  NIST  RMs 

Framework  vs  Framework,  through  Mappings 
Objective  means  to  all  of  the  above. 


SERVICES 


Over  50  functional  areas 

Over  half  directly  applicable  to  general-purpose  PTls 
such  as  CAIS. 

More  for  frameworks  defining  more  policy 
(development  process  management,  detailed 
integration  conventions). 

Extremely  complete  for  CAIS. 


SERVICE  OMISSIONS 

Time  Services 

Error  Handling  Services 

Input-Output 

Distinguish  uninterpreted  (e.g.  file)  data  from 
interpreted  (captured  in  data  model). 
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SERVICE  INCOMPLETENESS 


State  vs  Event  Monitoring 

Inadequately  distinguished  in  descriptions. 

Interchangeable  examples. 

Events  iff  DB  state  change,  often,  so  logically 
related. 


Data  vs  Task  Transaction 

Task  transaction  service  is  under  development. 

Task  transactions  are  "supported"  by  CAIS: 
Should  such  potential  applications  be 
discussed? 

Guidelines  are  needed: 

How  much  coverage  of  potential 
applications? 

Standard  terminology  to  capture 
availability  of  functions  (defined  vs 
presupposed  vs  facilitated). 
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SERVICE  INCOMPLETENESS,  cont'd 


Data  Interchange  addresses  common  format  but 
overlooks  other  essential  services. 

Support  for  detection  and  reconciliation  of 
multiple  instances  (representations)  of  the 
same  entity. 

Prevention  (or  intermediate  form)  of  multiple 
entities  with  same  unique  identifier. 

Exchange  and  reference  of  "foreign"  unique 
identifiers. 

Convenient  exchange  of  objects'  dependencies, 
such  as  typing  information,  components. 
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SERVICE  £IMENSIONS 


13  divisions  potentially  applicable  within  each 
Service. 


Attempted  to  apply  10  uniformly. 


ICE: 

Internal 

•  Conceptual  -  External 

ROD: 

Rules  - 

Operations  -  Data 

Related 

Services 

TIM: 

Types  - 

Instances  -  Metadata 

DIMENSION  REDUNDANCIES 

Data  is  redundant  with  e.g.  Internal,  External, 
Instances 

Omit. 

Types  are  a  subset  of  Metadata,  which  is  both  a 
Dimension  and  a  Service  area. 

Merge. 

ICE:  Internal  -  Conceptual  -  External 

ROD:  Rules  -  Operations  ^  Related  Services 

TIM:  Types/Metadata  >  Instances 
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-  (8ow4  Oft  on  (E(?)  model 

ift4cfW  "W  Oft  undwW'oi  lli>5ras 


•  I  oolso^"  ,  , 

.  0.01 4i&l  sef  Ot  Took  in-WCfoJeci  ^ 

.  CoAiAk  o4  ^  broetl  ca4e^oc»«4  -foick 


-  PWViWe  ^EiWniiblt,  in^cjfcie  Cftjj  ivunvb^ 

-  t>fc4ft.  ift^ejfc^Wft  jeniicej 

4oo\* 
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SLCSE 

TuTURC  ^<?ECT\0^5S 


•  SLCSE  € n (ti  Vcari) 

-  )(•  0  i«f  Xr\‘\«fn«>e« 

-  A«i«i»4to«\a.\  KbflrrvS  ^uppor*) 

.  Open  6lrcK*t  WAvirc. 

-  ‘Xmpftfweel  Pef4offw4r\ee 

.  fifliMdt  on  Be^flL'TeiT  CtW  (  Utef  Co(^co^n& 

•  SLCS6  Pro  duc^  I  tA^ion  (S  yeen) 

-  G  00.1  -W  4rokf»ji  oo  Swppuf  ^  jirodnei 

4o  KP/boo/'boA  cun-kedoa 

•  Sieve  Speeiol  Cuvfonnor  S  #n/f4!ei 

-Task  ordcf*  baveol  conirocJ  mechaoh/n 
~  ih  v't'a.lla'Hon 

-  CU.V*Vorr)ua4i  oO 
.  ^rainioQ 

-  oo'ii^o  n\ain  4«naACc 
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5LCSE 

mappln&exerci  se 
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A^tcr  lessens  lecurnei  dvr’mn  rtercK 
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SLC5E 

C0I1MENT5  ON  KEFERENCE  MODEL 


STREN&THS: 

-Oen^ftkily  corrtfcf  appr»^riflif« 
Stfr’vicc  dtfScrip+iims. 

**  Dimensions  muffip/iC 

perspec+»yej/cl#s«i*»p+»®ns  o^  a 
Sinntt  service. 


•  WCM<NesS£S: 

'More  examples  needed. 

-  Ntw  services  nee<J  re-f*’«e«^en'+: 

“  "Diwensiens”  f UE/RoO^TiM)^ 

C«n«*f1y«//  ^rntion*  ,  C4c.)/ 
o4’Kcr’  r^^^rreJ  ’4'« 


irt4cr  c  hanjeabty, 


•Aod^tionku  Service  Description/ s-. 
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~  RH  Section  l4:  FrawnCwerK  Dc/ini^icn/HMli'ficWhen 
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-  RcfMttcfy  Cf«o.+ic»/Modif»cn+»o*» 

•  ’’  Environment  DclefiOh  i4i 


Mapping  Quidalinea 


Appendix  A  -  Forms 


A, 3  Service  Mapping 
Effort  Namet  SLCSE 

Service  Namei  Replication/Synchroniaation  Service  (7.12) 

Applicable  definitions  and  mapping  guidelines  which  apply  to  this 
section  are  provided  in  Section  4.2.1  of  this  Mapping  Guideline 
document.  Fill  out  one  form  for  each  sevice  listed  in  Section  A. 2. 
If  your  model  has  additional  services  not  covered  by  the  list  in 
Section  A. 2,  then  please  attach  additional  forms  for  these.  Add  New 
Service  to  the  Service  name  at  top  of  form. 

At  Does  your  ISEE  effort  support  the  overall  concept  of  this  service? 

_  Not  applicable  (Discuss  in  comments  below) 

_  No  (Discuss  in  comments  below) 

_  Supports  alternate  concept  (Discuss  in  comments  below) 

_  Unable  to  determine  (Discuss  issue  in  comments  below  and 

identify  reason  as  to  ambiguity  or  incompleteness  in  NIST 
model  or  as  to  ambiguity  or  Incompleteness  in  your 
own  effort. ) 

X  Yes  (If  yea,  continue  below) 

_  Fully  implements  described  set  of  services 

X  Implements  a  subset  of  services  (List  unsupported  services) 

_  Implemented  as  part  of  another  service  (Give  reference  to 

these  other  services) 

_  Implements  a  superset  of  services  (Give  additional  services 

supported) 

_  Other  (Discuss  in  comments  below) 

B:  Dimensions  (Check  all  dimensions  that  are  mapped  for  this  service. 
Include  a  "Service  Dimension  Form”  for  each  such  mapped  dimension  for 
each  service.) 

_ X _  Conceptual  [required] 

X  Operational  [required] 

X  Related  services  [required] 

_  External  [recommended] 

_  Data  [optional] 

_  Rules  (optional] 

_  Types  [optional] 

_  Instances  [optional] 

_  Metadata  [optional] 

_  Internal  [optional] 

COMMENTS  t 

This  service  is  not  provided  for  Infrastructure  Database  or  Project 
Files  Hierarchy  Objects,  since  they  are  never  replicated  within  a 
distributed  environment  for  any  constructive  purpose  in  the  context  of 
SLC^B. 


Mapping  Guidelines 


Appendix  A  -  Forms 


A. 4  Service  Dimension  Form 
Effort:  SLCSB 

Service:  Replication/Synchronization  Service 
Dimension:  ICE  -  Conceptual 

Description  of  how  dimension  applies  to  this  service: 

The  SLCSE  provides  a  Replication/Synchronization  Service  for  Project 
Database  Objects. 

Within  a  heterogeneous  network  of  computer  nodes,  it  is  possible  for 
remote  applications  to  "check-out"  a  subset  of  information  contained 
in  a  SLCSE  Project  Database,  manipulate  that  subset  of  information, 
and  to  "check-in"  the  modified  information  to  the  Project  Database. 
Database  integrity  is  important  in  a  multi-user  environment  such  as 
SLCSB,  and  therefore,  it  is  possible  to  "lock"  the  instances  that  are 
checked-out,  and  "unlock"  them  when  they  are  checked  back  in. 

This  facility  is  provided  using  a  client-server  architecture,  where  a 
client  process  on  the  remote  node  requests  (over  the  network)  a  subset 
of  data  from  a  server  process  running  on  the  host  platform  of  the 
Project  Database.  Both  the  client  and  the  server  work  through  an 
interface  to  the  Entity-Relationship  Interface  (ERIF)  called  the  Hi^h 
Level  ERIF  (HLERIF),  which  is  a  highly  portable  Ada  package.  This 
package  provides  the  capability  to  operate  within  the  memory 
constraints  of  the  remote  computer  via  efficient,  self-automated 
"swapping"  operations  to  and  from  the  local  file  space,  and  also 
provides  data  file  formats  that  can  be  relatively  easily  transformed 
into  the  format  required  for  use  by  a  native  application. 


Give  an  example  of  this  dimension  for  this  service: 

The  SLCSE  Project  Management  System  (SPMS)  is  an  example  of  a  system 
that  uses  the  Replication/Synchronization  Service  provided  by  SLCSE, 
as  described  above.  The  SPMS  contains  Commercial  Off-The-Shelf  (COTS) 
project  management  tools  implemented  on  a  Macintosh  workstation  that 
communicates  to  the  SLCSB  Project  Database  over  the  network.  The 
Project  Management  Assistant  (PMA)  facet  of  the  RL  Knowledge-Based 
Software  Assistant  (RBSA)  program  and  the  Quality  Evaluation  System 
(QUBS)  are  other  examples  where  this  service  was  applied  for  tools 
implemented  on  workstations. 


*f;******«*****ft£i,^  q£  seryj[ce  Dimension  form********************** 
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Napping  Guidelines 


Appendix  A  -  Forms 


A. 4  Service  Dimension  Form 
Effort I  SLCSB 

Service:  Replication/Synchronization  Service 
Dimension:  ROD  **  Operations 

Description  of  how  dimension  applies  to  this  service: 

The  basic  set  of  operations  (create,  query,  update,  and  delete) 
applicable  to  this  service  for  the  Project  Database  are  provided  by 
the  "High-Level  Entity-Relationship  Interface  (HLBRIF)",  and  are 
listed  below: 

Create: 

"Add  Moni tor^Action" 

"Duplicate"  “ 

"Insert" 

Query: 

"Attribute_Brror__Message" 

"Collection  Error  Message" 

"Condi  tion"“ 

"Count" 

"Finalize" 

"Find^Backward" 

"Flnd“Forward" 

"First" 

"Get" 

"Get^Current" 

"Get~Error" 

"Get“lnstance_Storage" 

"Get~Monitor_Actlon" 

" Ge t “Ne X t_B ve n t " 

"Get~Swap_Count " 

" Ge t“Tes t_Er ro r " 

"Goto_Firit" 

"Ooto“Last" 

"Goto”Next" 

"Goto*"Previous" 

"HlerTf  Error  Message" 

"Image"”  ” 

"Initialize” 

"instance^Brror  Message" 

"Last"  ”  " 

"Local  Collection  Exists" 

"Login'"'  “ 

"Logout" 

"More^Brrors" 

"More”Mon I tor_Ac t ions" 

"More“Te8t  Errors" 
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■Print" 

"  Re  t  r  i  eve_Fro!n_Loca  1 " 

•Re  t  r i eve~From“s lose " 

" Re  t  r i e ve_Mon i t o  r_Ac  t i ons " 

"Test^Servera" 

"Value" 

Update: 

"Save_To_Local" 

"Save“To”sicae" 

■Set"*"  ” 

"Set_Instance  Storage" 

■Set“Matching^ 

■Sort" 

Delete: 

■Delete" 

"De.'stroy" 

■Destroy__Local_Col  lection" 

■  Reuno  ve_Mof  i  i  t  of _Ac  t  i  on  " 

Give  an  example  of  this  dimension  for  this  service: 

On  a  Macintosh  workstation,  retrieve  from  SLCSB  all  entities  of  the 
PROBLEM  entity  type,  passing  the  Retrieve__From__Slcse  operation  the 
boolean  value  of  'True'  for  the  "Reserve"  parameter.  This  locks  these 
entities  while  the  retrieving  application  operates  on  the  local  entity 
collection  until  the  Save_To_Slcse  operation  is  used  with  a  boolean 
value  of  'True'  for  this  operation's  "Release"  parameter. 


***« *******ft***gf|^  gf  Service  Dimension  porm**************'**'******* 
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A. 4  Service  Dimension  Form 
Effort!  SLCSB 

Service:  Repl icat ion/Synchronizat ion 

Dimension:  Relationships  Between  Services 

Description  of  how  dimension  applies  to  this  service: 

An  Entity-Relationship  model  of  the  dependencies  between  each  of  the 
SLCSB  services  was  developed  to  determine  the  relationships  between 
services.  Bach  service  was  modeled  as  an  entity  with  various 
"depends  on"  relationships  to  other  services.  An  analysis  on  the 
model  using  the  SLCSB  analysBR  tool  resulted  in  the  generation  of 
forward  and  backward  "trace"  reports  that  were  optimized  to  eliminate 
redundant  relationship  information.  Forward  trace  reports  on  a 
service  show  the  services  that  are  required  by  the  service.  Backward 
trace  reports  on  a  service  show  the  services  that  require  the  service. 

This  service  requires  the  following  services  which  are  provided  by 
SLCSB: 

OPTIMIZED  TRACE  REPORT 


TRACE  ON  ENTITY  7  12  replication  FORWARD 
9  LEVEL  RELATIONSHIP 

—  AS  A  MEMBER  OF  [all]  SUBSETS. 

7_12__repl  icat  ion  (FORWARD)  [object_management] 

1-""  7_12__repl  icat  ion  depends_on  7_2jdata_storage 

— >2-"  7_2__data_storage  depends_on”  1 1_1_message_delivery 

— >2-  7”2~data~storage  depends__on  15”l”2  common__data_descr 

— >2-  7”2''data~atoroge  depends^on  7_T6_gIobal__schema 

-->3-“  global_8chema  depends_on  ” 

15_1_2_common_data  Hescr  ” 

”  — 7_tS_global_8chema  depends_on  7_1_data_model 

This  service  is  required  by  the  following  services  which  are  provided 
by  SLCSB: 

OPTIMIZED  TRACE  REPORT 


TRACE  ON  ENTITY  7  12  replication  BACKWARD 
9  LEVEL  RELATIONSHIP 

—  AS  A  MEMBER  OF  [all]  SUBSETS. 

7_12_repl icat ion  (BACKWARD)  [object_management] 

1-  15_1_6_con8istency__mgt  depends_on  7__12__repl  icat  ion 
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Disclaimers 


•  Purpose  of  mapping  exercise  is  to  evaluate  the 
effectiveness  of  the  reference  model  to  describe 
environment  frameworks. 


o  The  purpose  is  NOT  to  evaluate  any  individual 
framework. 


•  Opinions  expressed  in  this  talk  are  the  personal 
observations  of  the  author  and  do  not  represent 
NIST,  the  NIST  ISEE  Working  Group  or  any  of 
those  involved  in  the  mapping  exercise. 
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Process 


•  Reference  model  based  upon  a  set  of  services. 
Each  service  described  by  up  to  13 
characteristics  (dimensions). 

•  A  mapping  form  was  developed. 

-  Each  service  described  on  a  separate  form. 

-  Three  dimensions  were  requested  for  each  service. 

•  Conceptual  —  What  service  does 

•  Operations  —  How  it  does  it 

•  Related  services  —  Impact  on  other  services  in 
framework 


•  Analysis  based  upon  forms  received  from  CAIS- 
A,  ECMA  PCTE,  AD/cycle  and  SLOSE 


Computer  Science  -  I  University  of  Maryland 
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•  Developed  Form 

•  Diecuseion  of  reference  model 

•  Sample  mapping  of  one  eei^vice  with  feedback 

•  Each  mapper  had  a  liaison  with  ISEE  WG 

•  One  month  to  do  mapping 


June  Meeting 

•  Mappers  believed  process  was  useful  and 
sucessful 

•  Kickoff  meeting  valuable 

•  SLCSE,  ECMA,  PCTE  and  CAIS-A  mapping  forms 
available  through  PSESARCH@NADC.NAVY.MIL 
archive 
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Positive  Feedback  to  Mapping 


•  Reference  model  useful 

-  to  understand  and  explain  architectures 

-  as  a  guide  to  improve  system's  descriptions/ 

documentations 

-  as  a  common  basis  for  discussion 

•  All  serviced  seem  applicable  to  SEE  frameworks 

•  New  Services  suggested 
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Environmen 


TOOLS 


FR/vMEWORK 


PLATFORM 


J 


FRAMEWORK 


PLATFORM 


TOOLS 


□  □  □ 
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I  FRAMEWORK 


FRAMEWORK 


1_1 


TOOLS 
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PLATFORM 


TOOLS 
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Issues  raised  by  mapping  -  1 


•  Group  assigned  responsibility  to  respond  to  item 
EC  -  NIST  ISEE  Executive  Committee 

-  PL  -  Platform  Services 

--  OM  -  Object  Management  Services 

-  TM  -  Task  Management  Services 

-  UI '  User  Interface  Services 

•  Data  dimension  possibly  redundant 

-  Data  relates  to  internal,  external  and  instances. 

-  Proposal  —  Delbte  Dati^Sflli|!^rge  Types  and 
Metadata  dimensions 

e  Tool  Registration  —  Too  distributed.  Merge  into 
one  chapter  [’•‘PL’*'] 

tS*  it « 

•  underlying  operating 
systems  services  (e.g«,  process  support, 
communication,  security,  backup,  Ul,  etc.  when 
under  control  of  the  underlying  platform) 

s  State  monitoring  (in  OM)  and  event  monitoring 
(in  TM)  seem  similar.  Should  there  be  a  common 
service?  [*TM‘*‘] 
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Issues  raised  by  mapping  -  2 


•  Data  interchange  (in  OM)  and  archive  service  (in 
OM)  seem  similar.  Merge?  [*OM*] 

•  State  monitoring  triggers  when  data  states 
change  in  repository.  Some  frameworks  include 
relationship  changes  also  (e.g.,  full  pre-  and 
post-conditions  on  events).  Extend  state 
monitoring?  [*OM*] 

•  F rameworks  versus  environments  —  How  much 
should  reference  model  cover?  (e.g.,  How  much 
of  degree  of  tool  integration  is  part  of  reference 
model?)  [*PL*] 

•  Security  models,  role  of  framework  security,  and 
relationship  of  security  chapter  with  access 
control  services  needs  to  be  addressed.  [*PL*] 

•  User  Interface  sections  obviously  incomplete. 
How  much  can  and  should  be  specified?  [*UI*] 


Computer  Science  -  University  of  Maryland  < 
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Issues  raised  by  mapping  >  3 


•  All  four  sample  mappings  are  based  upon  an  ER 
data  model.  Reference  model  needs  to  be  checked 
against  an  object-oriented  framework.  [’"OM*"] 

•  New  services  need  to  be  considered  (*ALL’*‘] 

rafiiw- 

if  * 
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Additional  Services  to  consider 


Time 

Error  reporting 

Framework  definition/modification  (Changing 
roles,  names,  tools,  personnel,  etc.) 

Tool  integration  (encapsulation  **  wrappers,^ 
**plug  and  play**  tool  slots) 

Object  Management  Navigation 


» l»  "f  €  e r aT# ^ 


«S^^vlC#£ 
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fl.  fBueoo 


ICSE13  Panel  Integration  from  the  perspective  of  the 

Environment  User 


appearance  and  similar  modes  of  interaction. 


ICSE13  Panel  ^tegration  from  the  perspective  of  the 

Environmeiit/Tool  Builder  (Cont.) 
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Tool  Integration  Issu 
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•  Framework  must  be  able  to  model  new  semant 

•  Reconcile  conflicts  in  data  models  &  behaviors 
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Tool  Integration 
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CNve  Development  Environments,  Inc. 
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tfvices,  framework  services,  and  environment  services.  The  following 
9ie  way  these  concepts  are  related: 
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INTEGRATION  MECHANISMS 


Dl "  Data  lintaroperability 

PM  <■  (Llfdt-Cyda)  Process  Management 


DATA  INTEGRATION  MECHANISMS 


Intorriai  forms  for  programs,  (by-)  products  of 
llf»“cyds  procsss,  documents  [e.g.  IRIS,  DIANA] 

data  translators  between  OMSs  (->  Dl) 

data  exchange  mechanisms,  canonical  data  forme 
(e.g.,  CAIS^  CEF,  CDIF,  P1 175,  IRDS 
exporMmport;  ->  Dl] 

common  schemas  (e.g.,  PMDB] 

type  interoperability  mechanisms  (e.g.,  SLI] 

name  conflict  resolution,  name  servers  (covered  by 
OM] 

schema  migration,  exchange,  and  translation 

self-describing  data  forms  (e.g.,  SGML,  CAIS-A  CEF, 
CDF;  -»  dI] 

data  translators 

(data)  modal  translators 

aemantic  integrity 

mattiod  (OO)  inheritance 

margbig  data,  schemas,  and  modsls(7)  (note;  related 
to  translation) 

synchroniation  across  duplicates  &  (distributed) 
rspHcat'se  (covered  by  OM| 
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PROCESS  MANAGEMENT 
INTEGRATION  MECHANISMS 


control  communication  mechanisms  [e.g.,  state 
mochtniama,  event  mechanisms,  concurrency 
aarvicaa,  massage  services,  dynamic  multiplatform 
(RPC^)  comm,  services,  invocation,  tool  interaction 
across  platforms  and  languages  (homooeneous  to 
heterogeneous),  network  services;  PM] 

dynamic  sychronization  of  multiple  views,  multiple 
contexts,  multiple  presentations 

control  executive  model/tool  composition  paradigm 
[note:  this  is  closely  related  to  communication 
mechaeiisms;  e.g.,  transactions;  pipes,  scripts, 
attribute  monitors,  general  life-cycle  pt  ocess  model 
enactment;  ->  PM] 

control  vitual  operating  system 

process  translators  (?) 

(message)  protocol  translation 

life-cycle  process  (method)  integrity 
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USER  INTERFACE 
INTEGRATION  MECHANISMS; 


usMT  interface  'look  and  feel'packages 


MISCELLANEOUS; 

tool  ancapaulation/do-encapsulation  (?) 

conventions  {e.g.,  for  naming] 

common  programmatic  (call)  interfaces 

tool  registration  and  deregistration 

uaer  customization  &  extension  features/packages 

policy-related  [note;  related  to  semantic  integrity;  e.g., 
management,  security) 
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User  Interface  Services 


User  Interface  Services  involve  all  aspects  of  the 
framework 

Conceptual 
•  Seeheim  Model 

Since  1982,  the  most  influential  user  interface  reference 
model  has  been  the  so-called  Seeheim  model,  defined 
by  a  group  of  designers  at  a  workshop  sponsored  by 
Eurographics  and  IFIP  in  Seeheim,  Germany. 


Users 


Summary  of  the  5th  Workshop  on 
Integrated  Software  Engineering  Environments  (ISEE) 

July  26, 1991 

William  Wong 
NIST/CSL 

Gaithersburg,  MD  20899 
(301)  975-334 
Fax  #  (301)  590-0932 
wong@swe.ncsl.nist.gov 


The  Fifth  Workshop  on  Integrated  Software  Engineering  Environments  (ISEE)  in 
conjuncdon  with  the  PCIS  (June  3-7)  and  IWCASE  (June  6)  workshops  took  place  in  Redondo 
Beach,  California  on  June  3-5,  1991.  The  workshops  were  hosted  by  TRW  and  Los  Angeles 
SIGAda  and  sponsored  by  the  National  Institute  of  Standards  and  Technology  (NIST),  the  U.S. 
Department  of  Commerce,  the  Ada  Joint  Program  Office  (AJPO),  the  U.S.  Department  of 
Defense,  the  International  Workshop  on  CASE  (IWCASE),  and  the  Special  Working  Group 
(SWG)  on  Ada  Programming  Support  Environment  (APSE). 

The  goal  is  to  identify  and  establish  a  consensus  for  the  U.S.  Federal  government  and 
industry  to  address  the  need  for  open  system  ISEE  and  software  tools  interface  standards.  The 
agenda  of  the  workshops  were  designed  to  support  each  other’s  activities  and  all  participants 
were  encouraged  to  participate  in  all  the  workshops.  This  will  provide  a  better  understanding  of 
the  overall  activities  from  the  various  working  groups  and  will  help  to  reduce  the  duplication  of 
efforts  and  redundant  initiatives  and  establish  synergism  between  the  participating  groups. 

The  ISEE  workshops  objectives  are: 

to  identify  and  explore  fundamental  issues  in  ISEE  areas; 

to  identify  the  needed  set  of  standards  that  define  a  comprehensive  interface  for 
integrating  software  tools; 

to  develop  guidelines  on  interfiuie  standards  for  ISEEs;  and 

to  provide  guidance  to  Federal  agencies  in  acquiring  software  development  and 
maintenance  environments. 
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The  workshops  were  attended  by  approximately  100  software  professionals  drawn  from 
the  U.S.  Federal  government,  industry,  and  academia.  Participants  also  included  European  and 
Japanese  software  professionals. 

The  ISEE  workshop  primarily  focused  on: 

1 )  enhancing  the  NIST  ECMA  ISEE  Reference  Model  Technical  Report  by  reviewing 
and  rewriting  new  services,  and  identifying  and  defining  the  services  related  to 
integration,  and 

2)  reviewing  the  results  cf  the  NIST  ECMA  ISEE  Reference  Model  mapping 
exercise. 

NIST  is  scheduled  to  publish  the  "ISEE  Reference  Model  Technical  Report",  version  1.0 
as  well  as  the  "Repon  on  Summary  of  Results  of  the  First  NIST  ISEE  Reference  Model 
Mapping"  by  the  end  of  September  or  early  October,  1991.  Working  Groups  included: 

Object  Management,  led  by  Lolo  Penedo,  TRW; 

Process  and  Task  Management,  led  by  Hal  Hart.  TRW; 

Interface  and  Platform,  led  by  Tricia  Obemdorf,  NADC;  and 

User  Interface,  led  by  Bob  Bagwill,  NIST. 

The  general  format  included: 

1)  the  NIST  ECMA  ISEE  Reference  Model  tutorial  session  given  by  Anthony  Earl 
of  HP  in  UK. 

2)  the  NIST  ECMA  ISEE  Reference  Model  Mapping  Exercise  Summary  chaired  by 
Sandi  Mulholland  of  Rockwell  International,  and  the  results  of  the  ISEE  reference 
model  mapping  exercise  summarized  by  Marv  Zelkowitz  of  the  University  of 
Maryland  and  NIST, 

3)  the  Integration  Services  session  chaired  by  Tricia  Obemdorf  of  NADC,  and 

4)  four  parallel  working  group  sessions. 

This  workshop  was  organized  and  coordinated  by  William  Wong  of  NIST,  Lolo  Penedo 
and  Hal  Hart  of  TRW,  and  Currie  Colket  of  AJPO.  Special  thanks  are  due  to  members  of  the 
NIST  ISEE  Executive  Committee  and  other  individuals  for  their  valuable  assistance  and  support 
in  the  planning  of  the  workshop.  They  are:  Bob  Bagwill  of  NIST,  Currie  Colket  of  AJPO,  Hal 
Hart  of  TRW,  Roger  Martin  of  NIST,  Sandra  Mulholland  of  Rockwell,  Tricia  Obemdorf  of  Naval 
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Air  Development  Center,  Lolo  Penedo  of  TRW,  Ian  Thomas  of  Hewlett  Packard,  and  Marv 
Zelkowitz  of  the  University  of  Maryland  and  NIST. 

The  6th  NIST  ISEE  Workshop  is  scheduled  for  October,  1991  in  Gaithersburg,  MD. 
NIST  will  be  the  host  and  sponsor  of  the  upcoming  workshop.  The  date  and  agenda  will  be 
announced  at  a  later  time.  The  lists  of  action  items  for  the  work  to  be  accomplished  before  the 
next  woiicshop,  the  summary  of  each  working  group,  reference  model  mapping  exercise  and 
integration  services  sessions  are  included  as  follows; 

a)  summaiy  of  action  items; 

b)  summary  of  schedule  for  completion  of  the  NIST  ISEE  Reference  Model 
document,  version  1.0; 

c)  summary  of  status  report  from  each  working  group; 

d)  summary  of  the  NIST  ECMA  ISEE  Reference  Model  Mapping  Exercise  session; 
and 

e)  summary  of  the  Integration  Services  session. 


a)  Summary  of  Action  Items. 


Action  Items 


Responsible  persons  Deadlines 


Coordinate  and  prepare  the  final  workshops  Hal  Hart  6/2 1,^1 

participation  list  Clyde  Roby 

Coordinate  and  prepare  the  Proceedings  of  NIST  Clyde  Roby  6/28/91 

ISEE  /  pas  /  IWCASE  Workshops  Bill  Wong 

Update  the  NIST  ISEE  working  group  e-mail  Tiicia  Obemdorf  7/19/91 

distribution  list 


Working  Group  Status  Reports: 
Object  Management 
PrcKess  Management 
Interface  and  Platform 
User  Interface 
Integration  session 
Mapping  Exercise  session 


6/14/91 

Lolo  Penedo 
Hal  Hart 
Tricia  Obemdorf 
Bob  Bagwill 
Tricia  Obemdorf 
Marv  2^1kowitz 
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Summary  of  the  ISEE  Workshop 

Bill  Wong 

6/21/91 

Coordinate  with  ECMA  TC33 

Bill  Wong 

ongoing 

Forward  new  sections  to  Marv  (the  RM  editor) 

Lolo  Penedo 

Hal  Han 

Tricia  Obemdorf 
Bob  Bagwill 

7/15/91 

Forward  the  RM  document  to  NISTEC,  Anthony 
Earl  for  review 

Marv  Zelkowitz 

8/1/91 

Review  of  NIST  ISEE  RM  document  (version  1.0) 

Marv  Zelkowitz 
Anthony  Earl 
NISTEC 

8/23/91 

Forward  the  revised  document  to  NIST  ISEE, 
ECMA  TC33,  other  relevant  groups 

Marv  Zelkowitz 
Bill  Wong 

8/30/91 

Coordinate  with  ECMA  TC33  for  comments 

Bill  Wong 

9/5/91 

Collect  all  the  comments  on  RM  document 

Marv  Zelkowitz 
BUI  Wong 

9/15/91 

Finalize  the  RM  document 

Marv  Zelkowitz 
NISTEC 

9/30/91 

Publish  the  joint  NIST  and  ECMA  ISEE  RM 
document  (version  1.0) 

Marv  Zelkowitz 
BUI  Wong 

10/91 

Arrange  and  hold  NIST  ISEE  Executive  Committee 
Meeting  -  plan  for  the  upcoming  workshop 

BUI  Wong 

TBD 

Arrange  and  hold  6th  Workshop 

BUI  Wong 

10/91 

11/91 

b)  Summary  of  detailed  schedule  for  completion  of  NIST  ISEE  Reference  Model 
Document,  version  1.0 

Marv  Zelkowitz  is  designated  as  the  editor  of  the  NIST  ISEE  Reference  Model  Document 
with  the  assistance  of  Anthony  Earl. 
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-  July  15 


1)  New  sections  from  all  the  group  leaders  to  Marv 

Object  Management  -  Lolo  Penedo 
Process  and  Task  Management  -  Hal  Hart 
Interface  and  Platform  -  Tricia  Obemdorf 
User  Interface  -  Bob  Bagwill 

2)  RM  document  from  Marv  to  the  following 
individuals  for  review; 

‘  NISTEC 
-  Anthony  Earl 

3)  Comments  due  back  to  Marv 


4)  Revised  document  for  review  from  Marv  to: 

-  NIST  ISEE 

-  ECMA  TC33 

-  other  relevar  i  groups 

5)  Comments  due  back  to  Marv 

6)  Finalize  the  document 

7)  Publish  the  ISEE  RM  document 
Version  1.0 


c)  Suinmary  of  status  report  from  each  working  2roup. 

1)  Object  Management  Working  Group 

Chair:  Lolo  Penedo,  TRW 
(213)  812-0595 

penedo@trwaicadia.sdd.trw.com 

Summary: 

Expertise/familiarity  w/  RM:  little  to  very  much 


-  August  1 

-  August  23 

-  August  30 

-  September  15 

-  September  30 

-  October  ? 
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Group  Activities; 

o  reviewed  OM  services  &  dimensions  definitions 
o  discussed  issues/question  pertaining  to  OM  services  and  global  RM 
o  reviewed  service  descriptions  (each  service  was  allocated  to  at  least  one  person), 

o  provided  answers/solutions  to  issues  from  mapping  exercise  and  reviews 

Accomplishments: 

o  Reviewed  all  text  associated  with  the  OM  services 
o  Provided  recommended  solutions  for  issues 
o  Identified  issues  for  future  discussion 
Action  items; 

o  T.  Strelich  -  will  review  3  services  by  June  14; 

o  L.  Penedo  -  is  section  boss  for  document,  i.e.,  will  review,  modify  and  integrate 
all  comments  about  OM  services  into  document,  which  is  due  to  Marv  of  NIST 
as  the  editor  of  the  RM  document  in  early  July. 

o  WG  Attendees  -  will  review  final  text 


DISCUSSION  ITEMS  (OM) 

1.  Issue;  OS  issues  as  related  to  "Process  Support"  service. 

Resolution:  This  service  is  not  supposed  to  ^al  with  processes  in  general;  it  is  there  only 
in  the  case  that  OS  processes  are  treated  like  objects  in  OMS.  Text  will  be 
changed  in  the  document. 

2.  Issue;  Deleting  "data"  dimension. 

Resolution:  no  apparent  problems  for  OM  serviass. 

3.  Issue:  Merging  "types"  &  "metadata"  dimension. 

Resolution:  No  problems,  titled  new  section  *Types/Metadata". 

4.  Issue:  What  to  do  when  some  dimensions  are  not  described  in  RM  document?  Should 

"Not  Applicable"  dimensions  be  noted? 
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Resolution: 


a)  unclear  -  try  to  put  text  whenever  possible  and  applicable 

b)  N/A  is  ambiguous  •  don’t  use  it  for  the  time  being 

5.  Issue:  Unclear  distinction  between  "State  Monitoring"  and  "Constraint"  Services. 
Resolution:  Merge  those  services. 

6.  Issue:  Data  Model  service  seems  out  of  place. 

Resolution:  Include  in  conceptual  dimension  of  "Metadata"  Service. 

7.  Issue:  Redundancy  of  'Tool  Registration"  service  across  RM. 

Resolution:  Deleted  Tool  Registration  service  from  OM  grouping  (assuming  it  is  kept  in 
Framework  Adm.). 

8.  Issue:  Is  Object  navigation  covered  anywhere? 

Resolution:  In  Query  and/or  Archive  and/or  Relationship  and/or  Data  Storage  services. 

9.  Issue:  What  is  the  difference  between  Data  and  Task  transaction? 

Resolution:  Added  clariHcadon  text  in  riata  transaction. 

10.  Issue:  No  services  for  Data/DBMS  like  administration  services. 

Resolution:  Future  discussion. 

1 1.  Issue;  Does  the  configuration  service  refer  to  CM? 

Resolution;  No,  it  deals  with  Composite  Objects  which  may  support  CM. 

12.  Issue:  Shall  non-persistent  data  be  addressed? 

Resolution:  Future  discussion. 

13.  Issue:  Consistency  in  terminology  OM,  DM. 

Re.solution:  Review  document  carefully.  OM  does  not  mean  0-0,  nor  ER;  it  means  data 
management  in  general. 

14.  Issue:  Heterogeneous  object  interchange. 

Resolution:  Future  discus.sion. 


Change  items  for  change  in  document: 

o  clarify  text  in  OS  Process  support 
o  delete  Data  sections  and  merge  Types  with  Metadata, 
o  merge  Constraint  and  State  Monitoring  Services, 
o  delete  Tool  Registration. 
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0  clarify  data  versus  task  transaction. 

0  clarify  meaning  of  "object", 
o  merge  Data  Model  and  Metadata  services. 


Future  Issues: 

o  Delete  OS  process  support  service  (Ln  OM  grouping)  or  generalize  service  to  deal  with 
OS  related  services  (teyond  process). 

0  Add  new  services  to  deal  with  Database  administration  services. 

o  Deal  with  non-persistent  data. 

0  Deal  with  heterogeneous  object  interchange. 

2)  Process  and  Task  Management  Working  Group 

Chair  Hal  Hart.  TRW 
(213)  812-0661 
halhait@ajpo.8e;.cmu.edu 


Summary: 

Expertise/familiarity  w/  RM:  This  group  of  participants  combined  to  yield  extensive  familiarity 
and  expertise  witli  both  the  RM  and  the  subject  area  (life-cycle  process 
management). 

Group  Activities: 

o  Developed  and  discussed  pioblemsAssues  with  current  RM  organization  and  definitions 
relating  to  Process  Management  (PM). 

o  Gained  consensus  on  moderate  reorganization  of  RM  section  (including  some  added  and 
some  grouped  services)  and  approach  for  dealing  with  appearance  of  overlap  with  OM. 

0  Broke  into  1-  or  2-man  subgroups  to  author  new  descriptions  of  each  re-organized  service 
section  (will  become  mainly  the  "Conceptual"  sections);  distributed  each  to  PM  WG. 
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Accomplishments; 

o  Renamed  section  "Process  Management  Services"  to  be  more  consistent  with  what  we 
perceive  to  be  common  community  terminology. 

o  Committed  to  converging  RM  PM  temiinology  with  SEI  Process  Glossary  distributed 
recently  by  Watts  Humphrey  and  Peter  Feiler;  we  will  provide  feedback  to  SEI  where  we 
have  detected  inadequacies  and  with  their  glossary. 

o  Developed  revised  list  of  PM  services  and  corresponding  new  list  of  RM  PM  subsections. 

o  Began  revision  or  re-writing  of  new  RM  PM  subsections. 


Action  Items; 

o  Hal  Hart  -  is  section  boss  for  document,  i.e.,  will  review,  modify  and  integrate  all  drafts 
and  revisions  about  PM  services  into  document;  Anthony  Earl  intends  to  assist  with  final 
writing: 

-  draft  due  to  WG  approx.  June  25 
■  completed  draft  due  to  NIST  in  early  July. 

o  Jim  King  -  will  continue  to  work  terminology/glossary  normalization  actions,  including 
both  review  of  new  RM  PM  usage  against  SEI  Process  Glossary  and  feedback  to  SEI 
about  our  detected  inadequacies  and  incompletenesses. 

o  All  Participants  -  will  review  revisions  and  drafts  distributed  at  workshop  and  provide 
feedback  to  section  boss  and  authors  (hopefully  via  e-mail  so  all  of  WG  can  see  it);  and 
wall  review  June  2S  draft  consolidated  PM  section. 


Discussion  Items: 

General  Overlaps  with  OM: 

General  Issue  Resolution:  Keep  OM  and  PM  sections  independent,  include  redundancy 
(e.g.,  storage  services)  where  it  is  known  that  some  SEE’s  will  provide  distinct 
sets  of  services  for  OM  and  PM.  But,  clarify  in  introductory  text  the  potential  for 
some  SEE’s  to  deal  with  both  uniformly  or  identical  services,  and  be  sure  that 
usage  of  the  RM  (c.g.,  mappings)  provides  distinction  between  SEE’s  with  totally 
separate  OM  &  PM  services  versus  partially/totaUy  merged  services. 
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1.  Issue:  Differences  between  Data  and  Event  Triggers. 

Resolution;  Data  triggers  always  deal  with  changes  to  persistent  data,  but  events  may 
occur  as  result  of  changes  to  the  execution  state  of  processes  which  may  or  may 
not  involve  persistent  data  in  different  SEE’s.  Hence,  Event  Triggers  must  be 
uniquely  provided  in  the  PM  section,  but  the  potential  for  cases  of  overlap  or 
equivalence  with  Data  Triggers  should  be  noted. 

2.  Issue:  Process  Transactions  versus  Data  Transactions. 

Resolution:  Meaningful  distinction  for  SEE’s  where  events  are  independent  of  changes 
to  persistent  data,  but  general  case  will  be  ttiat  Process  Transactions  also  involve 
some  notion  of  data  transactions.  General  "Scope"  issues  of  visibility, 
propagation,  applicable  constraints,  and  relation  of  scope  to  history  management 
apply.  Will  be  dealt  with  by  retitledAevised  section  6.3  titled  "Visibility/Scoping 
Services." 


Others ; 

3.  Issue:  New  Services,  esp.  Metrication. 

Resolution:  Previous  section  6.6  ("Audit  and  Accounting  Services")  will  be  generalized 
into  "Process  Control  Services,"  including  scheduling,  general  metrics  specification 
&  collection  (of  which  auditing,  accounting,  &  emerging  process  metrics  are 
specializations),  history  recording  selection,  and  simulation/analysis. 

4.  Issue:  Framework  Definition/Modification  Facility. 

Resolution:  Not  dealt  with;  probably  deferred  to  Framework  Administration  section. 

5.  Issue:  Function/Attachment  Integration. 

Resolution:  Opinion  was  that  this  is  dealt  with  adequately  in  the  OM  section  (as  an 
accommodation  to  object-oriented  approaches?)  and  does  not  impact  PM  section. 

6.  Issue:  Identify  Classes  of  Process  Information. 

Resolution:  Identified  classes  that  provide  context  for  all  Process  service  descriptions: 
(0)  Description  of  process  fragments  (process  assets) 

(a)  Description  of  software  process  (interpretable  by  humans) 

(b)  Description  of  software  process  (in  some  enactable  form) 

(c)  r>sscription  of  the  execution  state  of  a  software  process: 

products  manipulated  by  a  process  have  a  product  state 

some  parts  of  the  product  state  may  also  be  pan  of  the  execution 

state 

some  parts  of  product  and  execution  state  will  be  linked 

(d)  Description  of  history  of  software  process  execution. 
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7. 


Issue:  What  to  Do  about  SEI  Terminology  List 

Resolution:  We  will  adapt  to  SEI  Process  Glossary  where  it  applies,  and  provide  feedback 
to  SEI  where  we  detect  incompletenesses  and  inconsistencies. 

8.  Issue:  Process  Operations. 

Resolution:  Discussion  identified  a  list  of  Process  Meta-Model  Operations  (which  is 
reflected  in  revised  set  of  PM  services  below,  and  eventually  their  "Operations" 
dimensions,  with  refinement): 
process  scheduling 
metrication  &  its  specializations 
modifications  to  process  descriptions 
modifications  to  descriptions  of  executable  processes 
modifications  of  descriptions  of  executing  processes  (&  hence  to  their 
execution  states) 
history  record  selecdon 
simuladon/analysis 

9.  Issue:  Revision  of  Section  Structure  and  Contents. 

Resolution:  See  "Change  Items"  below. 

10.  Issue:  Granularity  -  Does  RM  imply  that  only  Coarse-Grained  Storage/Manipulation 

Support  is  needed? 

Resolution:  Check  that  text  does  not  assume  coarse  granularity;  check  that  Process 
Definition  (and  OM  storage  services  for  SEE’s  where  QMS  provides  PM  support) 
recognizes  distinction. 

11.  Issue:  Inconsistency  between  Meanings  of  'Task"  versus  "Process". 

Resolution:  Term  "Process"  will  be  used  consistently  henceforth  in  the  NIST  ISEE 
Reference  Model,  in  the  sense  of  the  implied  adjectives  "life-cycle"  or  "software 
development"  always  being  present. 


CHANGE  ITEMS  FOR  RM  PM  SECTION  RESTRUCTURING: 

New  PM  Section  Structure  (with  mapping  to  previous  &  draft  authors): 

(NOTE:  Although  new  subsections  6.3  >  6.6  are  moderate  regroupings  or  extensions  of 
scope,  the  WG  expects  that  almost  all  existing  text  will  be  reused;  however,  significant 
new  and  revised  text  is  also  expected). 

6  Introductory  Text  (Ian  Thomas) 

6.1  Process  Definition  Services  (6.1;  Hal  Hart  &  Anthony  Eaii) 

6.2  Process  Enactment  Services  (6.2;  Hal  Hart  &  Anthony  Earl) 

6.3  Visibility/Scoping  Services  (6.3;  Joe  Morin  &  Ron  Peterson) 

6.4  Process  State  and  History  Services  (6.4,  6.5;  Bob  Balzer) 


220 


6.5  Process  Control  Services  (6.6;  Ken  Shere) 

6.6  Resource  Management  Services  (6.7,  6.8;  Bill  Ett,  Jim  King) 


Future  Issues: 

o  Synchronize  with  OM  section  for  clear  handling  of  SEE  instances  where  service 
classes  are  independent  versus  those  SEE’s  where  OM  services  serve  some  dual 
or  support  role  for  PM  (esp.  definition  storage;  transactions;  triggers) 

o  Negotiation  with  Framework  Administration  section  for  handling  of  tool 
registration 

o  Negotiation  with  Framework  Administration  section  for  handling  of  metrication 
services 


3)  Interface  and  Platform  Working  Group 

Chair:  Tricia  Obemdorf 
(215)  441-2737 
tricia@nadc.navy.mil 

Sutiunary: 

The  Interface  and  Platform  Working  Group  of  the  NIST  ISEE  Workshop  met  on  the 
afternoon  of  Tuesday,  June  4,  1991.  On  Wednesday  morning,  time  was  to  be  used  to  generate 
the  assigned  text.  The  first  priority  of  the  group  is  to  address  all  of  the  sections  of  the  NIST 
ISEE  RM  that  are  not  covered  by  the  other  working  groups,  so  we  coveted  the  following  sections 
during  our  meeting: 

7  -  Communication  Services 

9  -  Tools 

10  -  Security  Services 

1 1  -  Framework  Administration  and  Configuration 

It  has  previously  been  agreed  that  the  new  Integration  section  will  not  be  completed  for  the 
September  document,  so  no  discussion  was  held  regarding  this  section.  (See  the  summary  of  the 
Integration  session  held  Wednesday  afternoon.) 

The  attendance  was  very  snudl,  leaving  us  only  one  m  two  authors  per  section. 
Comments  from  the  mappers  as:  well  as  outstanding  issues  were  addressed.  The  results  are 
provided  in  the  following  paragraphs. 
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SECTION  7  •  Communication  Services 


We  agreed  with  the  initiative  already  taken  in  the  recent  work  on  the  RM  which  suggested 
that  the  "Message  Services"  secdon  should  be  broadened  to  include  other  sorts  of  communication 
services,  including  RPC,  "file"  sharing,  pipe-like  mechanisms,  and  session  dialogues  and 
protocols,  as  well  as  the  message  delivery  services  already  discussed  in  the  section.  We  also 
discussed  the  role  of  such  session  issues  as  connecdon-oriented  versus  connectionless  protocols 
and  synchronous  versus  asynchronous  mechanisms.  One  author  took  an  assignment  to  work  on 
broadening  the  section  in  accordance  with  our  discussions. 

One  question  we  considered  in  this  section  was  the  one  raised  by  the  CAIS-A  mapping 
regarding  where  to  place  CAIS-A’s  I/O  protocols,  model,  and  services.  It  was  agreed  that  this 
would  logically  fit  into  the  Communication  section  of  the  document,  but  that  it  should  be 
postponed  until  some  revision  after  the  September  document. 


SECTION  9  -  Tools 

In  a  move  to  consolidate  the  coverage  of  Integration  in  the  RM,  it  was  agreed  that  the 
Tool  Integration  section  would  be  moved  to  Section  12  (Integration).  We  do  believe  that  there 
is  a  place  in  the  RM  for  a  section  on  Tools,  although  we  discussed  several  different  placements, 
drawing  no  final  conclusion.  Because  of  the  ambiguities  inherent  in  the  term  "tools",  we 

discussed  alternate  titles  (e.g.,  "Domain-specific  _ "  or  "Life-Cycle  Support 

_ "),  but  we  came  to  no  final  conclusion  here  cither.  We  also  agreed  that  we  should  keep 

a  software-oriented  tools  list  such  as  is  currently  in  the  RM,  noting  that  it  is  an  example  and  that 
there  are  similar  tool  lists  for  CAD/CAM,  Office  Automation,  and  other  disciplines  of  interest. 
One  author  took  an  assignment  to  woik  on  rewriting  the  general  text  regarding  tools;  a  second 
author  took  an  assignment  to  consolidate  the  "Tool  Registration"  text  currently  spread  throughout 
the  document  (see  discussion  of  Section  11). 


SECTION  10  ••  Security 

It  was  agreed  that  it  was  important  to  keep  a  section  on  Security  and  tliat  there  are  likely 
to  be  a  number  of  other  similar  sections  which  should  be  added.  Making  this  one  part  of  a  larger 
section  on  "Policy  Enforcement  Services"  was  discussed,  but  it  was  felt  that  it  was  premature  to 
attempt  that  for  the  September  document  We  also  discussed  location  of  the  section,  but  decided 
it  should  be  left  where  it  is  (i.e.,  after  Tools  and  before  Framework).  We  agreed  that  the  contents 
needed  to  be  btitter  articulated  and  more  in  line  with  the  format  used  in  all  the  other  sections 
(i.e.,  providing  a  discussion  according  to  the  applicable  dimensions).  One  author  agreed  to  work 
on  this  assignment,  based  on  a  related  paper  which  he  has  authored  for  a  related  effort. 
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SHCnON  1 1  -  Framework  Administration  and  Configuration 

The  first  issue  discussed  here  was  with  regard  to  the  disposition  of  a  consolidated  section 
on  Tool  Registration.  Although  the  group  originally  agreed  that  this  should  be  placed  in  the 
Tools  section,  the  sentiment  was  not  extraordinarily  strong  and  this  decision  was  subsequently 
reversed  by  the  executive  committee,  leaving  Tool  Registration  in  this  section.  Several  other 
issues  raised  by  the  mappers  were  considered  for  placement  in  this  section,  but  upon  discussion 
all  of  them  seemed  to  fall  into  some  other  category,  most  notably  one  that  would  be  called 
"Environment  Administration"  as  opposed  to  Framework  Administration.  As  there  is  no  home 
for  such  a  section  within  the  current  scope  of  the  document,  it  was  agreed  that  these  additions 
would  have  to  wait.  Thus  one  author,  with  the  assistance  of  another  attendee,  agreed  to  work 
on  the  Metrication  section  as  well  as  the  general  introduction. 

Several  other  questions  raised  by  the  mappers,  along  with  a  few  noted  in  the  Framework 
Administration  section  of  the  current  draft,  were  considered.  The  following  is  a  list  of  those 
questions  and  the  disposition  of  them  proposed  by  the  IPWG. 

o  Installation  Procedures,  including  Tool  Management  -  include  in  Environment 
Administration  or  perhaps  Integration. 

o  Framework  Definition/Modification  •  include  in  the  Subenvironment  (Views) 
Service. 

o  Environment  Definition/Modification  •  include  in  Environment  Administration. 

o  Environment  Deletion  -  include  in  Environment  Administration. 

o  OMS  Schema  Management  -  include  in  Section  5  (OM  Services). 

o  Groupware  Management  -  include  in  Section  5  (OM  Services). 

o  Resource  Registration  and  Mapping  -  include  in  Section  5  (OM  Services). 

o  Services  provided  by  underlying  OS/Platform  -  discuss  how  to  handle  these  in  the 
Mapping  Guidelines. 

o  Exception  HandUng/Error  Handling  Services  -  include  in  5.14,  6.5,  and 
Integration. 

o  Project  Management  Integration  -  include  in  Section  6  (PM  Services). 

o  Tool  Invocation  (including  command  interpreter?)  -  include  with  Tool  Integration. 

o  Editors  (textual,  graphical)  -  include  in  Common  services/Encapsulation. 
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o  Display/List  services  •  include  in  Common  Services/Encapsulation. 

o  Help  facilities  •  include  in  Common  Services/Encapsulation. 

o  Time  services  -  not  clear  where  it  goes,  but  it  is  not  the  responsibility  of  the 

IPWG  within  the  current  document. 

o  Repository  Creation/Modification  -  include  in  Environment  Administration. 

o  Tool  encapsulation/de-encapsuladon  ^  include  with  Tool  Integration. 

Mappers’  comments  which  we  did  not  address,  on  the  assumption  that  they  would 
naturally  be  picked  up  by  other  working  groups,  are: 

o  interchange  formats 

o  presentation  styles 

Two  of  the  five  assignments  were  completed  prior  to  close  of  the  mt«ting.  The  remaining 
three  are  agreed  to  be  delivered  within  two  weeks  following  the  close  of  the  NIST  ISEE  meeting. 


4)  User  Interface  Working  Group 

Chair:  Bob  Bagwiil,  NIST 
(301)  975-3282 
rbagwill@nist.gov 

Summary: 


Expertise/familiarity  with  UI  RM: 

Except  for  Marv  2^1kowitz,  all  the  participants  were  new  to  the  UI  group.  Bob  Bagwiil 
took  over  as  leader  when  Brian  Gapper  could  no  longer  participate  in  the  NIST  ISEE  activity. 
Bob  Bagwiil  presented  two  alternative  UI  models,  the  Seeheim  and  Arch  models 


Group  Activities: 

o  reviewed  the  contents  of  the  previous  draft,  which  was  identical  to  the  ECMA 
TR/5S  Technical  Report 
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0  rC'Confmned  the  decision  that  the  ECMA  version  was  insufficient  as  a  basis  for 
a  user  interface  services  reference  model. 

o  decided  XI 1  would  be  retained  only  as  an  example  of  an  architecture  to  be 
mapped  against  the  UI  reference  mcdcl. 

o  discussed  appropriateness  of  Seeheim  and  Arch  models. 

o  mapped  Object  Management  Services  against  the  UI  domain. 

o  added  two  service  areas  Internationalization  and  User  Assistance  Services 

o  changed  name  of  section  to  "User  Interface  Management  Services." 


Action  items: 

o  Bob  Bagwill  -  will  prepare  rough  draft  of  new  UI  section  and  email  to  attendees 
o  Marv  Zelkowitz  -  will  review  draft 
0  WG  attendees  -  will  review  the  text 


d)  Smnmary  of  the  NIST  ECMA  ISEE  Reference  Model  Mapping  Exercise  Session. 

Chair  Sandi  Mulholland,  Rockwell 

Marv  Zelkowitz,  University  of  Maryland  and  NIST 


Summary: 

The  NIST  ISEE  Reference  Model  Mapping  Exercise  Summary  session  of  the  5th  NIST 
ISEE  Workshop  was  held  Tuesday  morning.  All  attendees  of  the  3  workshops  were  invited. 
During  the  Fourth  NIST  ISEE  Workshop,  it  was  recognized  that  in  order  to  test  the  effectiveness 
of  the  Reference  Model,  it  would  be  necessary  to  map  the  set  of  services  provided  by  various 
activities  into  the  set  of  services  provided  by  the  NIST/ECMA  ISEE  reference  model. 
Accordingly,  in  March,  1991  a  meeting  was  held  to  discuss  this  mapping  exercise.  The  following 
iixlividuals  and  activities  were  tepre.sented; 
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1.  Geoff  Clow  of  SofTech  representing  CAIS-A 

2.  Anthony  Earl  of  HP  representing  ECMA  PCTE 

3.  Barbara  Meyers  of  IBM  representing  AD/cycle 

4.  James  Milligan  of  Rome  Laboratory  representing  SLCSE 

5.  Hal  Pierson  of  SPC  representing  the  CIS  ATIS  activity 

A  mapping  form  was  generated  and  repents  from  each  of  the  5  activities  was  due  in  mid-May. 
This  session  of  the  Fifth  Workshop  was  a  report  on  the  results  of  this  mapping  exercise. 

The  reference  model  is  based  upon  13  characteristics  (dimensions)  for  each  of  the 
approximately  40  services  of  the  model.  In  order  to  make  the  overall  effort  for  each  mapper 
reasonable,  only  three  dimensions  were  requested  for  each  service: 

1.  Conceptual  -  What  the  service  does 

2.  Operadons  -  How  it  does  it 

3.  Related  Services  -  Which  other  services  are  related  to  this  dimension 

During  die  session,  four  of  the  mappings  were  discussed.  The  CIS  mapping  was  delayed 
and  will  be  conveyed  to  NIST  at  a  later  date.  (Note:  Copies  of  the  SLCSE,  ECMA  PCTE  and 
CAIS-A  mappings  were  submitted  to  the  PSESWG  archive  and  can  be  retrieved  by  anyone  with 
internet  access.  Send  mail  to  PSESARCH@NADC.NAVY.MIL  with  the  subject  line  ‘help’  to 
get  further  information.  The  AD/cycle  mapping  has  to  be  obtained  direedy  from  IBM.) 

General  comments  on  the  mapping  exercise  were: 

1.  There  was  agreement  that  such  a  mapping  exercise  is  a  useful  activity.  It  helped 
each  of  the  mappers  to  understand  their  own  architecture  better  and  helped  to 
determine  places  where  either  their  own  designs  or  their  own  documentation 
needed  to  be  altered. 

2.  The  reference  model  and  the  mapping  exercise  provided  a  common  basis  for 
discussing  alternative  environment  frameworks. 

3.  All  services  in  the  reference  model  seemed  relevant  to  the  mappers.  In  addition, 
a  few  new  services  were  suggested  for  inclusion  into  a  later  draft  of  the  model. 
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Some  issues  raised  by  the  mappers  included  the  following: 

1.  There  was  general  confusion  concerning  the  placement  of  platform  -  supplied 
services  outside  of  the  services  explicitly  designed  for  the  environment  framework. 
For  example,  many  native  systems  included  underlying  backup  services  (e.g., 
DEC’S  VMS  for  SLCSE,  IBM’s  MVS  for  AD/cycle),  so  it  was  not  clear  if  such 
services  are  explicitly  part  of  the  environment  framework.  It  was  clear  that  the 
reference  model  document  needs  to  explain  this  better.  The  reference  model  is  a 
description  of  the  services  provided  to  tools  executing  on  the  framework.  Whether 
these  services  are  provid^  specifically  by  the  framework  implementation  or 
passed  through  by  the  underlying  native  operating  system,  is  an  architectural  issue 
and  outside  of  the  ;ealm  of  whether  the  service  is  supplied  or  not. 

2.  Tool  registration  concepts  need  to  be  collected  in  one  place  in  the  document. 
Also,  the  scope  of  the  document  --  environment  frameworks  versus  full  life  cycle 
tool  support  that  needs  to  be  clarified. 

3.  The  data  dimension  was  deemed  redundant  (e.g.,  it  only  appears  once  in  the 
version  of  the  reference  model  document  used  at  the  meeting).  The  internal, 
operations  and  external  dimensions  provided  sufficient  detail  to  replace  this. 

4.  The  metadata  dimension  was  also  redundant.  There  is  a  special  metadata  service 
and  most  of  the  other  metadata  issues  seem  like  cases  of  the  types  dimension. 

5.  Several  services  seemed  redundant.  The  various  working  groups  were  to  consider 
merging  the  following  pairs: 

a.  State  monitoring  and  Event  monitoring 

b.  Data  interchange  and  Archive  service 

6.  Several  chapters  were  obviously  incomplete  and  needed  additional  service 
descriptions:  Security,  Framework  administration,  Communication  services  and 
User  interfaces. 

7.  All  four  reported  mappings  were  based  upon  an  ER  model  of  the  data  repository. 
It  would  be  useful  to  obtain  an  object-oriented  mapping  (e.g.,  ATIS)  to  test  against 
the  reference  model  service  descriptions. 

8.  New  services  that  were  proposed  included: 

a.  Timing  features  --  elapsed  time,  time  of  day 

b.  Standardized  error  repenting 


227 


c.  Framework  definitions  -  changing  roles,  names,  tools,  personnel,  etc. 

d.  Tool  integration  issues  --  encapsulation  "wrappers,"  "plug  and  play"  tool 
slots 

e.  Environment  servicing  --  tool  installation,  modification,  tailoring 


e)  Summary  of  the  Integration  Services  Session. 
Chair:  Tiicia  Obemdorf 


Summary: 

The  Integration  session  of  the  5th  NIST  ISEE  Workshop  was  held  Wednesday  afternoon. 
Ail  attendees  of  the  3  workshops  were  invited. 


BACKGROUND 

At  the  4th  NIST  ISEE  Workshop,  there  was  a  brain-storming  session  during  which 
everyone  was  encouraged  to  speak  up  with  anything  they  felt  constituted  an  environment 
"integration  mechanism".  No  time  was  spent  on  defining  just  what  that  meant;  instead  we  relied 
on  a  common  intuition  to  come  up  with  something  that  would  be  representative  of  the  wide  range 
of  services  that  might  be  needed.  Following  that  workshop,  the  list  was  organized  slightly,  and 
the  result  is  attached  to  this  report 


OBJECTIVE 

For  the  purposes  of  the  5th  NIST  ISEE  Workshop,  a  more  structured  approach  was  taken 
to  the  Integration  session,  since  tiie  real  question  now  is  how  Integration  should  be  represented 
in  the  NIST  ISEE  RM  This  session  began  by  discussing  various  possible  definitions  for 
"integration"  and  examining  several  ways  in  which  various  authors  have  attempted  to  characterize 
it.  Following  those  discussions,  we  took  up  the  question  of  how  to  address  it  in  the  RM. 


DEFINITIONS  AND  CHARACTERIZATIONS 

The  session  started  with  the  examination  of  a  number  of  definitions  and  characterizations 
of  "integration"  from  various  authors.  Through  discussion  of  these  aspects,  a  common 
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understanding  of  integration  developed  among  the  participants.  Currently  this  common 
understanding  can  best  be  expressed  in  a  series  of  statements  as  follows. 

o  Integration  is  about  putting  parts  together  in  such  a  way  that  they  work  together 
towards  some  goal. 

o  This  goal  involves  the  parts  working  together  smoothly,  correctly,  easily, 
cost-effectively,  etc. 

o  Integration  is  about  agreement. 

o  Integration  is  not  monolithic:  it  is  complex  and  is  only  understood  by 
understanding  a  number  of  different  areas  from  a  number  of  different  perspectives. 

o  To  completely  describe  integration,  one  must  consider  answering  at  least  the 
questions,  "what",  "why"  (which  relates  to  the  "goal"  mentioned  above),  and 
"how"  (which  relates  to  die  mechanisms  that  resulted  from  the  4th  ISEE 
brainstorming  session). 

o  Integration  is  nut  something  that  a  single  entity  either  has  or  does  not  have; 
instead,  it  is  a  property  of  the  relationship  between  two  or  more  things.  (Thomas 
and  Nejmeh) 

In  addition  to  the  typical  characterizations  of  integration  (data,  process,  control,  presentation),  we 
discussed  "semantic"  integration  and  die  goal  of  reducing  tools  to  their  "essence",  with  all  other 
features  provided  by  the  framework  into  which  they  are  integrated. 

After  examination  of  different  attempts  to  characterize  integration  and  integration 
features,  it  was  possible  to  answer  a  few  questions.  It  seemed  to  be  the  group’s  feeling  that 
"Integration"  is  not  a  layer,  as  it  is  sometimes  depicted  in  reference  model  or  architectural 
diagrams.  Nor  is  it  a  sendee  per  se’,  although  there  are  a  few  services  which  it  was  felt  are 
unique  to  integration  (e.g.,  a  common  data  repository,  triggers,  encapsulators,  niters). 


REPRESENTATION  IN  THE  REFERENCE  MODEL  DOCUMENT 

One  of  the  difticulties  in  getting  a  handle  on  Integration  in  the  context  of  the  reference 
model  appears  to  be  the  fact  that  the  scope  of  the  current  reference  model  is  environment 
framewt^s  and  frameworks  are  largely  motivated  by  desires  for  achieving  integration.  In  other 
wtnds,  since  the  rationale  for  having  frameworks  is  that  they  provide  factorization  with 
enforcement,  which  naturally  leads  one  to  desire  maximum  commonality  within  that  factorization, 
it  is  hard  to  tell  a  "framework  service"  from  something  tliat  one  might  call  an  "integration 
service"  or  "integration  mechanism".  However,  following  the  discussion  of  defrnitions,  it  was 
possible  to  address  this  separation  to  some  extent. 
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Four  questions  were  put  before  the  group: 

1.  Is  Integration  a  Reference  Model  dimension? 

2.  I,s  Integration  a  policy? 

3.  Should  there  be  a  separate  section  for  Integration  Services? 

4.  Should  Integration  be  covered  in  a  separate  model/document? 

Although  there  was  some  support  for  answering  "yes"  to  the  first  question,  it  seemed  to  be  the 
sense  of  the  group  that,  if  done  at  all,  this  would  not  suffice.  No  one  really  seemed  to  pick  up 
on  the  second  question,  which  would  suggest  that  that  did  not  make  much  sense.  The  conclusion 
of  the  group  was  a  combinadon  of  short-term  and  long-term  approaches  which  can  be 
characterized  as: 

3a.  For  the  September  document,  discuss  only  what  is  known  today 

the  issues,  laying  out  the  "space"  to  be  covered  by  an  eventual  Integrati 
on  secdon  or  model 

the  reladonship  of  integradon  to  the  existing  services 

4a.  Do  a  proper  development  of  an  Integradon  reference  model  for  future  presentation, 
either  as  a  separate  document  or  as  an  eventual  secdon  of  an  evolving  NIST  ISEE 
RM  document 

keep  in  mind  that  an  RM  is  descriptive 

keep  in  mind  that  Integradon  is  one  of  several  ways  of  looking  at  and 
describing  frameworks. 

Some  pragmadcs  were  also  brought  up.  It  would  be  unwise  to  create  a  part  of  the  current 
RM  document  which  would  undoubtedly  be  changing  faster  than  the  test  of  the  document.  It  will 
also  be  important  to  find  out  who  else  is  woridng  on  what  parts  of  such  an  Integradon  RM. 
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INTERNATIONAL  WORKSHOP  ON  CASE 

(IWCASE) 


CASE  STANDARDS  COORDINATION 
UPDATE  MEETING 


Thoirsiday,  June  6, 1991 
S:30am-Noon 
Sheraton  Hotel 
Redondo  Beadb,  CA 

In  Coi\|unction  with  NIST  ISEK  and  PCIS  Workshops 


STANDARD  UPDATE  REPORTS 


DavidSfaarcm 

Nortli  Americ&n  Chairman 
CASE  Standards  Coordinatian  Committee 
c/o  CASE  Associates  Inc. 

15686  S.  Bradley  Road 
Oregon  City,  OR  97045 
(508)  656-0986 
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IWCASE 

CASE  STANDARDS  COORDINATION  UPDATE  MEETING 

Standard  Update  Reports 


•  CALS  Industry  Steering  Group  >  Software  Products  Committee 

•  CDIF  •  ElA  CASE  Data  Interchange  Format  Technical  Committee 

•  ECMATC33PCTE 

•  ZEEE’CS  PI  175  >  A  Standard  Reference  Model  for  Computing  System  Tool 
Interconnections 

•  IGES/PDES  -  Software  Products  Committee 

•  NIST/CSL  -  NIST  IEEE  Working  Group 

•  NGCR/PSESWIG  -  U.S.  Navy  Next  Generation  Computer  Resourcea/Project 
Support  Environment  Standards  Working  Group 

•  U.S.  TAG  for  ISO/IEC  JTC1/SC7 


Expect  to  Receive  Reports  From: 

•  CAIS-A 

•  PCIS 

•  ANSI  IRDS 

•  ISO  IRDS 

•  AD/Cycle 

•  Cohesion 

•  STARS 

•  OMG 
and  others 
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IWCASE  Inc. 


STANDARDS  COORDINATION  UPDATE  MEETING 

In  Conjunction  u*ith  NIST  ISEE  and  PCIS  Workshops 

Thursday,  June  6.  1991 
8:30  am  -  Noon 
Sheraton  Hotel 
Redondo  Beach,  CA 

STANDARDS  UPDATE  REPORT 

Oritniziuon  Name:  CALS  Industry  SteerinE  Group 

Contact  Person:  Thomas  G.  Baker — ^206^ 

Name  of  Projeci/irorkins  Group  Sofiu-are  Products  Committee  (SPC) 

Purpose  of  Siandard; 

The  Computer-Aided  Acquisition  end  LoRistic  Support  Initiaiive  represents  an  efion 
bv  the  hoD  to  improve  quhlitv  and  decrease  costs  in  the  acouisition  and  support  of 
veepon  systems  through  the  automation  of  iniegraied  processes  The  SPC  is 
addressing  roeihods  of  bringing  softe^^are  products  into  the  CALS  environment 

Scope  of  Standard: 

The  CALS  initiative  vlll  imoaei  DoD  standards  related  to  all  aspects  of  weapon  svsiem 
acquisition  and  support.  The  SPC  is  addressing  the  subject  of  CALS  compatibility  with 
the  software  functional  standards  D0D-S7D  2167A  and  7935  A. 

Objective  of  Standard: 

The  objective  of  the  SPC  is  to  studv.  document  and  recommend  on  the  CALS  compliance 
of  software  funciionaJ  standards,  life  cvcle  processes  and  deliverables  for  the: 

Near  Term  «  Define  requirements  for  disitai  delivery  of  infortaaiion  products. 

Long  Term  -  Define  issues  and  potential  solutions  for  accessing  the  data 

contained  in  information  products. _ 
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Current 

The  SPC  his  cooipleied  iti  analysis  of  Near-Term  obieeiives  and  is  finalizing 
the  Near»Term  Report.  The  group  will  continue  work  on  Long-Term 
objectives, _ 


Plans  (vith  Milestones  and  Schedule  Dates); 
Submit  Near-Term  Report 

Prepare  updated  Position  Paper 

Continue  analysis  of  Long-Term  issues. 


Publications  Available/Produced: 

Software  Products  Committee  (SPC'  Position  Paper,  dated  April  6,  1990, 


Liaison/Coordination  with  Other  Standard  Groups; 

The  group  has  conducted  joint  meetings  and  presented  to  several  software  standards 
making  organiiations  including  the  IEEE  CS-Pl  I'^S.  BIA-CDIF,  ISO  TCI  S4/SCe(STEP). 
and  PDES. 


Future  Plans/Trends; 

3-  Provide  reauirements  to  PDSS. 
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ProbJ*m8/lo»u*«/Nodt; 

Th»  group  vould  btntfit  from  additional  participation  of  people  vho  U99 
and  mainitin  th»  8ofwar*  products.  Ne^  members  are  welcomed. 


Piaast  provide  ihe  Reference  Model  used  by  your  standard  group  and  other 
graphical  representations  used  to  depict/position  your  standard. 

KEEP  YOUR  REPORT  TO  3  PAGES  and  FAX  to  Dave  Sharon  at  (503)  656-3207  by 
May  31.  1991.  Copies  ^'ill  be  distributed  to  those  attending  the  June  6th  meeting. 

Thank  you  I 


David  Sharon 
North  American  Chairman 
FAX:  (503)656-3207 

Phone;  (503)  656-0986 


Orgaziizadon  Name: 

CDIF  -  EIA  CASE  Data  Interchange  Format  Technical  Committee 
Contact  Person 

Stds.  Coord. :  Burt  Parker  (703)  883  5519 
Chair :  Mike  Imber  011  44  71  636  4213 

Name  of  Project/Woilidng  Group  : 

CDIF 

Purpose  of  Standard 

To  provide  a  neutral  format  for  the  interchange  of  data  between  CASE  Tools, 
in  me  form  of  a  fanrdlv  of  3  standards,  covering  Framework,  Transfer  Format 
and  Standardized  CASE  Meta-model. 

Scope  of  Standard  : 

To  cover  all  information  required  to  be  interchanged  between  CASE  Tools, 
both  Semantic  and  Presentadon,  through  Standardized  CASE  Meta-model 
and  extensibility  mechanism. 

Objective  of  Standard 

to  aid  the  development  of  open  systems,  by  enabling  users  to  move 
information  between  CASE  Tools  in  different  environments  and  platforms. 

Current  Status 

Aim  to  prnriurp  TTitenm  Standard  as  basis  for  prototyping  effort  in  mid  1991 
In  parallel  will  prepare  draft  for  Proposed  Standard  based  on  expanded  scope 
and  feedback  from  Prototypes  and  coordination  with  other  Standards 
Groups. 

Plans  (with  Milestones  and  Schedule  Dates)  : 

To  produce  Interim  Standard  in  mid  1991,  then  proceed  with  drafts  for 
Proposed  Standard  based  on  feedback  and  consultation  with  other  Standards 
Groups.  Timescale  dependant  on  consultation  progress. 

PublicadoRS  Available/Pzoduced 

Internal  Drafts  of  aU  three  standards 

Liaison/Cooidioation  with  other  Standards  Grows  : 

Regular  liaison  with  PDES/SPC,  PDES  Data  Dictionary,  IEEE  P1175  and 
CALS/SPC.  Proposal  for  joint  working  group  with  ECMA  TC33  CPCTTE). 
Contact  with  ISO  and  ANSI  IRDS, 

Future  Plazis/Trends: 
see  Plans 

Problems/lssues/Needs 

Need  ongoing  coordination  with  otiier  standards  CTOups,  as  already 
commenced,  to  ensure  greatest  applicability  of  the  CZDIF  work  to  other 
standards  efforts. 
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IWCASEInc. 

STANDARDS  COORDINATION  UPDATE  MEETING 

In  Conjunction  with  NIST  ISEE  and  PClS  Workshops 

Thursday,  Juna  6,  1991 
8:30  am  •  Noon 
Sheraton  Hotel 
Redondo  Beasb,  CA 


STANDAEDS  UPDATE  REPORT 


Organization  Name; 

Contact  Person: 

Name  of  Project/Working  Group: 


M  wi  r«iogg,oN/ 
TC--^-;.  fCTfe. 


Purpose  of  Standard: 


Scope  of  Standard: 

_ _ iSeglrtfhtt  ^  i^b 9,^ tj . 


Olyectire  of  Standard: 
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Current  Stetui 


Probltmt/Ifittes/Nottds: 


PImic  provide  the  Reibrenee  Modd  used  by  your  standard  group  and  other 
grstphieal  rapraaentatioQS  used  to  depict/position  your  standard. 

KEEP  YOX7B  REPORT  TO  3  PAGES  and  FAX  to  Dave  Sharon  at  (603)  656'3207  by 
May  31»  1991.  Copies  will  be  distributed  to  those  attending  the  Jime  6th  meeting. 

Thank  youl 


David  Sharon 

North  American  Chairman 
FAX:  CS03)66&3207 
Phone:  (503)  656-0986 


fh 
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**  TOTAL  PAGE. 004 


n^^CASE  Inc. 

STANDARDS  COORDINATION  UPDATE  MEETING 

In  Corgunction  with  NIST  ISEE  and  PClS  Workshops 

Thursday,  Jvme  6, 1991 
8:30  azn  -  Noon 
Sheraton  Hotel 
Redondo  Beach,  CA 


STANDAEDS  UPDATE  REPOET 


Organization  Name: 

Contact  Person: 

Name  of  Project/Working  Group: 


CO/ry\fiiATtoa  TOOlS 
"3  oh  ■  T  hfi  ir/yy 


Purpose  of  Standard:  ^ 

Tools 

I*  > 

2.  AYiodgi  '^rTool  ~ 


^  3.  Sl^ndard'tfKt  lan/fuA^e  CSTL)'fp 

Scope  of  Standard:  b^TUfeen^Toofb . 


,  .  ,  -r  -r -  r  - - -  w 

R>r  CormpuT(/)^  S^STP/yn  Tbol  TrrrerConi^&fTionS 


^monr\ffctJor\S 


m 

ki'.uiA 


r  /o 


arec-cs  P//75 


Problems/Iuuea/N»edr: 

£&oli^(Act  rlun^c,  ~r/ail  uic  D<='iod. 

s/  '  -J 


Please  provide  the  E/eference  Model  used  by  your  standard  group  and  other 
graphical  representotions  used  to  depict/position  yopr  standard. 

KEEP  yOXJR  REPORT  TO  S  PAGES  and  FAX  to  Dave  Sharon  at  (603)  656-3207  by 
May  31, 1991.  Copies  will  be  distributed  to  those  attending  the  June  6th  meeting. 

Thank  you! 


David  Sharon 

North  American  Chairman 
FAX:  (503)656-3207 
Phone:  (503)656-0986 
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IWCASE  Inc. 


STANDARDS  COORDINATION  UPDATE  MEETING 

In  Conjunction  with  NIST  ISEE  and  PClS  Workshops 

Tfturiday.  June  6.  1991 
8:30  a«  •  Noon 
Sheriion  Hotel 
Redondo  Beaon.  CA 

STANDARDS  UPDATE  REPORT 

OrganlzeUon  Ntiae:  I GES/PDES  Organization 

Conieci  Person:  Thomas  G.  Baicor  -  (206)  23-4>623^ 

Name  of  Projeci/Working  Group:  Software  Products  (SP) 

Purpose  of  Standard: 

■Ihe.dtvelQfimgm  of  a  sefiet  of  Standards  for  the  Bzchange  of  Data  to  provide  a 

nejitraljaechanism  capable  of  describing  product  data  throughout  tne  life  _ 

■cyclr.Qf_a  product,  independent  from  anv  particular  Computer-Aided  system  The _ 

namra  ffrthis  detcriPtion  Till  make  itjyttafele  not  orJvJor  neutral  file  eiehanee 
but  also  as  a  basis  for  imniament/pg  jnd  Sharing  product  databases  ar.dji»-chiving 
S£..yj|g  farmed  to  bring  sofra-are  and  its  associated  orodoctt  into  the  STEP 
environ  ioent  . . .  . . 

Scope  of  Staxtdard: 

The  scope  of  the  software  considered  includes  all  software  embedded  in  or  associated 
Vith.  anv  Product  dejcribable  bv  PDES/STEP.  Software  product  data  describes 

Ct^.«iCfmtaUL.dflign,  impifoitntatipp.  (coder  test  and  support  docutpentation  such  as 
user  t  jnanuals.  Inauilatlon  instructions  etc. 

Objective  of  Standard: 

The  objective  of  Software  Products  is  to  develop  the  STEP  models  for  softvare  product 
d_ita  supportine  the  entire  life  evcie  _ 
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I 


Plant  (vlih  Milrtionas  and  Schadule  Laiat): 

rouo  it  awaiting  final  atsprova]  as  a  oroiec;  u 


rQv.'pvlll _ 


ent  on  the  Appiieaiion  Aciiviiv  Modal. 


Publications  Availabla/Proaucad; 


Liaison/Coordination  with  Other  Standard  Groups: 


Futura  Plani/Trendi: 


[f  iTlKJa^  WlsWil^inTTfHJO 


'i! 


! 

Th«  group  it  inwrtiltd  in  obialnlnir  modtH  froo  other  orgininHons  addff »inB 
th»  MchanM  of  lofivtrt  inforroation.  Ntv  m»mbtr>  «r»  voicom»d,  As  thig  is  a 
falflv  ntv  group.  partlcipaUon  prcvidtc  t  gfat  opponunitv  for  membtri  to 
makt  a  altenificant  coniribuUon  to  Softvart  Proctucn  fpraaantatlon  in  STEP, 

Plaaat  providt  th«  RaftrtAct  Modal  uatd  by  your  standard  group  and  other 
graphical  rtprasentations  used  to  depict/position  your  standard. 

KEEP  YOUR  REPORT  70  3  PAGES  and  FAX  tc  Dave  Sharon  ai  (503)  656-3207  by 
May  31,  1991.  Copies  will  be  distributed  to  those  attending  the  June  6th  meeting. 

Thank  you! 


David  Sharon 
North  American  Chairman 
FaX:  (503)656-3207 

Phone;  (503)  656-0986 

1 

» 


1 
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IWCASS  Inc. 

STAl^ARDS  COORDINATION  UPDATE  MEETING 

la  Coojuaetion  with  NIST  ISBS  and  PCIS  Workshops 

Thursday,  Juna  6, 1991 
8:30  am  •  Noon 
Sharaton  Hotal 
Radondo  Baaeh,  CA 

STANDARDS  UPDATE  REPORT 


Orsanization  Name: 
Contact  Person: 


NIS7/CSL 

W1 111am  Wong  (301)975-3341 


Name  of  ProjeetAVorkine  Group:  NIST  ISE£  Working  Group _ 

Purpose  of  Standard: 

Provide  guidance  to  Federal  agencies  In  acquiring  software  development  and 


maintenance  environments  (ISSEs). 


Scope  of  Standard: 

Identify  and  stimulate  the  plans  end  coaaknation  needed  amonq  key  software 


es  and  relevant  standards  activities  for  consensus  direction 


on  open  systems  ISEEs. 


Oldactiira  of  Standard: 

Identify  and  explore  fundamental  issues  In  ISEEs  areas;  Idenfify  the  needed 


set  of  standards  that  define  a  comprehensive  interface  for  Integrating 


software  tools;  and  develop  guidelines  on  Interface  standards  for  ISEEs. 
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Currtnt  Statiu: 

Enhanct  tht  NIST/ECMA  Reference  Model  document  for  NIST  publication,  and 
revlaw  tha  rasuUs  of  rtftranct  modal  mapping  axareUa. _ 


Plttu  (with  Milittonat  and  Sehadula  Datat): 

CoenpTata  the  ravisad  NIST/ECMA  Rafaranca  Modal  document  and  publish  it  as 

tha  first  version  of  tha  NIST  Refarenca  Model  doemnant  by  the  end  of 
Saptambar  1991. 


Publicationa  Available/Produeed: 

The  NIST/ECMA  Reference  Model  Working  Draft  and  the  NIST  ISEE  Reference 
Model  Mapping  Guidelines  draft. _ 


Liaiaon/Coordination  with  Other  Standard  Groups; 

ECMA/TC33.  DARPA/STARS,  AJPQ/PCIS.  NGCR/PSEWG,  USAF/STSC>  POSIX,  IgE, 

IWCASE,  AIAA,  ECMA/PCTE,  CIS,  CAIS-A,  OMfi,  POES,  IRDS,  P1175.  P1201. 


Future  Plana/Trands: 

Develop  the  NIST  Reference  Modal  for  a  full  environment. 
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Probltmi/lMtttf/Natdi; 

Naed  voluntMfs  htiD  from  loftwrt  and  svsttm  conwnunitlas.  Ftddral  agencies 


and  tetdemle.  ttpeclallv  In  the  areas  of  u$er  interface,  integration  and 
aaeurltv  ttrvICfSt - - 


Please  provide  the  ReDirenoe  Model  used  by  your  standard  group  and  other 
graphical  representations  used  to  depiet^position  your  standard. 

KEEP  YOUR  REPORT  TO  3  PAGES  and  FAX  to  Dave  Sharon  at  (603)  656*3207  by 
May  31, 1991.  Copies  will  be  distributed  to  those  attending  the  June  6th  meeting. 

Thank  you! 


David  Sharon 

North  American  Chairman 
FAX:  (603)e6&3207 
Phone:  (603)6660986 
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BCMA/ra3/90161  a>n«l) 


FlfBTB  L  OvmO  Rdbnoee  Model  StracoBe 
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TOTAL  P.0C5 


IWCASS  Inc. 

STANDARDS  COORDINATION  UPDATE  MEETING 


In  Conjunction  with  NIST  ISSE  and  PCIS  Workahopi 


Thuraday,  Juna  6, 1991 
8:80  am  -  Noon 
Sharaton  Hoial 
Radondo  Baaeb»  CA 


STANDARDS  UPDATE  REPORT 


Organization  Name: 
Contact  Paraon: 


Objaetiva  of  Standard: 
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Futurt  Plant/Trezids: 


Probl«ini/lMuis/N«9di: 


^  Pltait  provid*  th*  lUftnnee  Mod«l  usad  by  your  standard  group  and  oth«r 
graphic  raprasantadoni  usad  to  dapiet/poiition  your  standard. 

KEEP  YOUR  REPORT  TO  3  PAGES  and  FAX  to  Dava  Sharon  at  (603)  656*3207  by 
May  31, 1991.  Copias  will  bo  distributed  to  those  attending  the  Jtme  6th  meeting. 

Thank  you! 


David  Sharon 

North  American  Chairman 
FAX:  (603)666-3207 
Phone:  (603)666-0986 


^  \Njl  cLo  vvrf  Ka.vc. 

(liosela  £CM^  OAxd  NIST  /SB^ 

Ojr^  ^  CLS  \^r^uM  pv-e-fer  ‘iro 

arUpi  Me.  vTaiW  InirDd^e.  ^  Me.. 

(Dor  ^^eraJ  dli^vers  oM  In'hsrfaji^ 

rifiXtiAt/viJ’  -/o  4Ae-  Op  IPSBs,  CficluAct 

yvelwrrtiA^  ^  user  L^'herPiLees  ^  prMLejujvY’ks  ^  duvucl 

4^  irihrpK^es 
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IWCASE,  Inc. 


STANDARDS  COORDINATION  UPDATE  MEETING 

In  conjunction  with  NIST  ISS£  and  PClS  Workshops 

Thursday,  June  6, 1991 
StSOam-Noon 
Sheraton  Hotel 
Redondo  Beach,  CA 

STANDARDS  UPDATE  REPORT 


Organization  Name:  U.S.  Technical  Advisory  Group  (TAG)  for 

ISO/IBC  Joint  Teehnicu  Committee  1  ( JTC 1 ) 
Subcommittee  7  (SC7)—Software  Engineering 

Contact  Person:  Roger  U.  Fuji!  213/831-0611  z2420 

Logicon,  Inc: 

222  West  Sixth  Street 
San  Pedro,  CA  90733 

N ame  of  Project/W orking  Group:  U.S.  TAG  for  ISO/IEC  JTC  1/SC7 
Purpose  of  Standard: 

The  U.S.  TAG  for  ISO/IEC  JTC  1/SC7  is  the  organization  that  provides  the 
reprasentation  of  various  U.S.  interests  related  to  the  scope  and  program  of  work  of 
ISO/IEC  JTC  1/SC7.  See  Current  Status  for  standards  projects  active  in  ISO/lEC  JTC 
1/SC7. 

Scope  of  Standard: 


.  TAG  for  ISO/IEC  JTC  1/SC7 
.  ^  »  *  C 1/8C7.  JifiBSion  statement  for 

.standards  for  managsTosnt  ischniquss,  supporting 
..  A..  - - - 1  maintainanes 


Me  pw  mree  yesrs,  we  u  oeisgates  to  iou/Uii 
1/^7  n^tmiii^have  bMtt  mfiluential  in  enaading  the  scope  to  include  softwi 
engineering.  The  standards  projects  do  not  include  prqjeehi  for  programming 
languages,  computer  graphics,  o£Bce  document  interdisnge  format  and  document 

database  management  sytbews  Lmluded  in  the  work  of 
othtf  ISOwC  JTC  1  subcommittees.  The  scope  of  each  standard  includes 
ror  international  use  and  is,  in  most  mass,  hsssd  on  a  National 

standards. 
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Objaetivt  of  Standard: 

Scopa  and  objeetivis  of  each  standard  are  included  in  the  proposal  for 
developing  the  standard  and  is  usually  based  on  consensus  developed  during  the 
early  stages  development.  It  is  influenced  by  the  reference  document  and  by  the 
delegates  attending  and  participating  in  the  technical  discussions  of  the  working 
groups. 

Current  Status: 

JTC  1/SC7  Working  Group  1: 

•  Chareing  Techniques  for  Sofkwara  Development, 
including  uee  in  CASE  tools,  proeesi  flow,  data  modeling, 

state  transition,  data  flow,  and  data  structure  [adding  more  techniques] 

e  Conventions  for  U  sage  of  Symbols  and  Icons  [new  project) 

e  Survey  of  Diagramming  and  Charting  for  Inference  Systems  [new  project] 

JTC  1/SC7  Working  Group  2: 

e  Software  System  Documentation  [revision  of  current  international  standard] 

e  Support  Graphics  for  Consumer  Software  [new  project] 

•  Management  of  Information  Transfer  Between  Life  Cycle  Phases  [new  project] 

JTC  1/SC7  Working  Group  3: 

•  Selection  and  Evaluation  of  CASE  Tools  [new  project] 

•  Evaluation  of  Software  Product  Quality  Charaetaristies,  includes 

subeharaeteristici,  measurement  and  rating  [xwar  approval  as  standard] 

•  Lifs  Cycle  Management  Proeesies  [early  stages  of  work] 

•  Seftwart  Confifuration  Management  [new  project] 

•  Quality  Requirements  and  Testing  Directives  [newprcjeet] 

•  Software  quality  EugiBoaring  [new  project] 

JTC  1/8C7  Working  Group  5: 

•  Xaftrcnee  Model  ibrlafttreiatieB  System  Engineering  [final  etages  of  work] 

•  Mapping  ofStandards  to  Roftrenes  Model  ibr  Information 
Syetem  Engineering  [development  stage] 

•  Claaoifieation  of  Software  [early  stages  of  work] 

Plans  (with  Ifflastonta  and  Schadula  Dataa):  Contact  R.  Ftgii  for  dataili. 
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Publications  Available'Produced: 


U.S.  TAG  meeting  summary,  ISO/IEC  JTC  L'SCT/WG  working  papers, 
committee  correspondence,  and  ISO/IEC  JTC  L'SC7  meeting  summary  are 
distributed  to  UJS.  TAG  members.  Approved  XSO/1EC  JTC  1/SC7  standards  are 
available  through  the  American  National  Standards  Institute.  U.S.  TAG  does  no 
have  any  formal  publications. 

Liaison/'Coordination  with  Other  Standards  Groups: 

U.S.  ASC  X3,  DoD,  NISO,  EIA,  lEEE/CS,  NIST,  NSIA,  ASQC,  NASA 

Other:  ISO  TC166/SG2,  TC159,  JTC  1/SCl,  JTC  1/SC18,  JTC  1/SCl:  EC 

TC66,TC66. 

Future  Plans/Trends: 

Plan  includes  advancing  U.S.  National  Standards  in  the  area  of  software 
engineering  as  International  Standards.  Principal  sources  of  U.S.  National 
Standards  includes  voluntary  accredited  standards^eveloping  organizations  such  as 
the  EEE/CS  Software  Engineering  Standards  Subcommittee,  government,  and 
other  National  Standards.  Trend  is  toward  describing  ihimeworks  within  which 
standards  are  developed  or  used  to  attain  desired  degrees  of  software  system 
fhnctionality  and  interouerability.  Attached  is  an  example  of  such  a  framework  for 
standardization  currently  being  considered  for  use  in  ISO.TEC  JTC  USC7.  See 
attached  "SC7  Overview:  Work  Items.” 

Problemwlssues/Needs: 

Broader  representation  of  interests  and  more  active  participants  in  the  U.S. 
TAG  activities  are  needed  to  represent  U.S.  national  positions  during  international 
meetings. 

Extensive  commitment  of  time  and  resources  is  needed  to  be  an  effecrlve 
participant  at  any  level  of  standardization  in  addition  to  the  understanding  of 
procedures  and  protocols  for  success. 

Coordination  workshops  such  as  the  IWCASE  Coordmaticii,  NIST/ISEE, 
PClS,  and  Joint  X3  Satabass  Systems  Study  Group  (DBSSG)  and  ISO/EC  JTC 
1/SC21  TAG  sponsored  meeting  on  the  "Convergence  of  Open  Systems 
Zatereonneetion  (OSD  and  Data  Management  Standards,’^  are  necessary  to  foster 
eommunieation  among  standards  ds velop«»  investigating  interoperability  issues. 

A  globel  frsmswork  of  softwsrs  engineering  proeesees  including  software 
quality  mesim  end  indicators,  evaluation  and  selection  of  CASE  tools,  practical 
guidanet  about  the  msnagement  of  the  products  of  each  life  cycle  phase,  and  services 
assoedated  with  an  integrated  software  engineering  environment  is  needed. 

Submitted  by:  TM.  Kurihera 

Member,  US.  TAG  for 
ISO/IEC  JTC  1/SC7 
70S/695-4470 
May  5, 1991 
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SC7  OVERVIEW:  WORK  ITEMS  (CONT.) 
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IWCASE  Inc. 

STANDARDS  COORDINATION  UPDATE  MEETING 

In  Cox^jimction  with  NIST  ISEE  and  PCIS  Workshops 

Thursday,  June  6, 1991 
8:30  am  •  Noon 
Sheraton  Hotel 
Redondo  Beach,  CA 


STANDARDS  UPDATE  REPORT 


Scope  of  Standard: 
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ProblemB/IsBuei/Needi: 

/UaU:  "/^rSS"  o 

CJXS''  b  4^  toLicil  ils  AITPS  . 


Please  provide  the  Reference  Model  used  by  yoiir  standard  group  and  other 
graphical  representations  used  to  depict/position  your  standard. 

KEEP  YOUR  REPORT  TO  3  PAGES  and  FAX  to  Dave  Sharon  at  (503)  656-3207  by 
May  31, 1961.  Copies  will  be  distributed  to  those  attending  the  June  6th  meeting. 

Thank  you! 


David  Sharon 

North  American  Chairman 
FAX:  (503)656-3207 
Phone:  (503)65&0986 


CALS,  PDES  and  Software  Products 
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Software  Products 
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specifications,  user  manuals,  etc. 


Software  Products 


266 


The  software  component  of  a  delivered  system  was  being 
ignored  in  the  product  standards  development  arena. 
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readiness,  and  reduced  life  cycle  cost 


CALS  -  The  Conce 
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Information  referencing/retrieval  capability 

Views  of  information  can  be  created  by  the  user  as  needed 

Requirements,  design,  test,  etc.  information  can  be  kept 
coordinated  and  up-to-date 


CALS  -  The 
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DoDI  5000.2  of  23Feb91  demands  data  "delivered  in  digital 
form  unless  clear  and  convincing  analysis  shows  this  not  to 
be  cost  effective  when  assessed  across  the  life  cycle" 


271 


CONTRACTOR  GOVERNMENT  CONTRACTOR  GOVERNMENT  CONTRACTOR  GOVERNMENT 
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The  resulting  "product",  be  it  missiies,  software,  or 
buiMbigs,  is  merely  a  manifestation  of  that  database. 
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Education  /  Training 
Small  Business 
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Communications  /  EDI  Committee 
Data  Base  Management  Committee 
Intelligent  Systems  Committee 
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Relationship  Between  Activities 
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CALS  Standards 


Other  Industry  Standards 
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fadlitatlld  by  cross  participation 
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This  requires  the  creation  of  a  new  kind  of  standard 
-  the  product  data  standard 
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with  their  own  internai  proprietary  database)  working 
together  -  reiiabiiity  anaiysis  with  cost  anaiysis 

Concurrent  Engineering  -  improvements  here  are 
probabiy  the  biggest  payoff  in  both  flow  time  and  dollars 
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on  requirements  for  exchange  and  sharing  of  product  data 

Maximize  the  use  of  existing  technoiogy  and  deveiop  the 
new  technology  necessary  for  completion 
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-  Support  for  electronic  products 

Assumes  a  person  is  available  to  interpret  data  meaning, 
i.e.  a  hole  vs  a  rod 
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Not  "just"  a  graphical  representation,  not  "just"  geometry, 
but  a  complete  definition  of  the  product  and  its  associated 
data  across  all  life  cycle  phases 


ISO  TCI  84  /  SC4  (STEP) 
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SC4  (STEP)  -  Organization 


S 

*5 

•o 

o 

3 

•o 

o 

a 

2 

'& 

■o 

o 

o 

O) 

c 

(0 

o 

X 

o 

•o 

c 

(19 

c 

o 

2 

c 

<b 

(/S 

2 

a 

o 


s 

(/) 


o. 

3 

2 

c 

o 

(0 

> 

< 

c 

o 

E 

0) 

O) 

(Q 

c 

(0 


o 

0) 


& 

s 

jS  o> 
-J  c 
CO  = 


3) 

c 

■o 

3 

o 

c 

CO 

(B 

£ 

(5 

c 

o 


o 

to 

O) 

Q> 


(0 

•o 

o 

*5 


.s  (0  ^ 

-K  e  i*- 


o 

o 


£ 


s  ■g 


E 

E 

O 

O) 

c 


s  's'  i 

“  OL 


o 

H 

o 

(/> 


UJ 


(0 

■o 

c 

(0 

3> 

■ 

CM 

o 


0) 


o 

3 

•o 

O 


CO 

O 


2 

c 

o> 

(0 

a> 

Im 

Q. 

0> 


o 

3 

•o 

O 


o 

3 

TJ 

O 

£ 

0> 

(0 


—  CO 
<  £ 


■u 

c 

(0 

c 

o 

■■V 

to 

o 


(0 

3 

O 


G 


c 

o 

E 

gl 

o 

> 

0) 

o 

D. 

UJ 

h- 

cn 

I 

If) 

G 


o> 

c 

to 

0) 

0) 

o 

c 

(0 

E 


c 

o 

o 

B 

CD 

o 


287 


WG7  -  Implementation  Specifications 


Software  Products 


Scope  of  effort 
Tasks  in  work 


Standards  Coordination 
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Software  Product  Standards 
Coverage  and  Future  Direction 
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practices,  most  are  not. 
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of  US  DoD  software  practices,  most  do  not. 


Agreements  on  Overall  Approach 
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A  mailing  matrix  was  developed  between  the  groups.  All  work 
generated  by  one  group  is  being  mailed  to  each  of  the  other 
groups. 
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CALS  Software  Products  Committee 
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CALS  SPC  Charter 
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2.3  Support  vitw  of  ■  tool 

What  does  it  take  to  make  a  tool  successftil  in  an  ot)ganizadon? 

Perhaps  the  most  indirect  interconnection  between  an  orsanization  atKl  a  tool  is  the  support 
elements.  Suf^pon  elements  are  those  things  that  an  oigartization  must  provide  to  maximize  the 
benefits  of  a  tod: 

1.  Policies:  Policies  are  written  descriptions  of  what  job  ftmcdons  must  perform  what 
acdvities  in  edidch  life  cycle  phases.  Policies  may  also  be  called  Directives,  Instructions, 
or  Methodologies. 

2.  Techniques:  Techniques  are  written  descriptions  of  how  to  perform  an  activity.  Tech¬ 
niques  may  also  be  called  methodologies,  methods,  or  procedures.  See  QEEE  P1016.2. 
Guide  to  Software  Design  Descriptions,  as  an  example. 

3.  Work  product  suundards:  Work  product  standards  art  written  descriptions  of  the  items 
(documents,  code,  or  data)  that  must  be  produced  in  an  activity.  Work  product  standards 
may  also  be  called  documentation  format  standards.  See  the  foUowing  standards  as 
examples: 

3.1.  ANSI/IEEE  Std  830-1984,  Software  Requirements  Specifications 

3.2.  AI4SI/IEEE  Std  1016.1,  Software  Design  Descriptions 

3.3.  ANSI/IEEE  Std  829-1983,  Software  Test  Doctimentation 

3.4.  ANSI/IEEE  Std  828-1989,  Software  Configuration  Management  Plans 
3J.  ANSI/IEEE  Std  730-1984  (Rev  1989),  Software  Quality  Assurance  Plans 

3.6.  ANSI/IEEE  Std  1012-1986,  Software  Verification  and  Validation  Plans 

3.7.  IEEE  Std  1074,  (in  process).  Software  Life  Cycle  Processes 

3.8.  IEEE  Std  1058.1-1987,  Project  Managemem  Plans 

4.  Measurements:  Written  descriptions  of  how  to  quantitatively  evaluate  work  products 
(measurements  may  also  be  called  metrics).  See  the  follow!^  standards  as  examples: 

4.1.  IEEE  P1044,  (in  process)  Standard  for  CHassilication  of  Software  Errors, 

Faults,  and  Failures 

4.2.  IEEE  P1045  (in  process).  Standard  for  Software  Productivity  Metrics 

4.3.  IEEE  Std  982.1-1988,  Dictionary  of  Measures  to  Produce  Reliable  Software 

4.4.  IEEE  P1061,  Standard  for  Software  Chiality  Metrics  Methodology 

5.  Traming:  Ttairting  is  erqrerience  in  the  applicatitm  of  support  elements. 

6.  Tools:  Tools  ate  mechanizatinu  tiiat  aid  or  replace  human  effort 

Support  elements  aid  a  person  who  is  new  to  a  job  or  tool  by  providing  the  answers  to  the 
following  questions: 

1.  What  am  I  supposed  to  do?  When  do  I  do  it?  -  Policies 

2.  How  am  I  supposed  to  do  it?  -  Techniques 

3.  What  am  I  sipposed  to  produce?  •  W)ik  produa  standards 

4.  How  will  I  know  it  is  a  good  work  product?  -  Measwements 

5.  Where  do  I  get  the  answer  to  these  question?  -  Training 

6.  What  is  the  easies  way  to  do  the  ri^  thing?  -  Tools 
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2.4  Tool  to  organization  interconnection  standard  profiie 

A  context  for  designing,  using,  or  testing  a  tool  is  estatdished  by  the  oiganization  that  will  use 
the  tool.  One  step  toward  growing  knowledge  of  die  context  is  to  identify  each  of  the  intercon¬ 
nections  or  relationships  between  an  organization  and  its  tools.  The  ‘Tool  to  Organization  In¬ 
terconnection  Standard  Profile"  form  at  the  end  of  this  chapter  has  been  designed  to  help  identify 
all  of  these  interconnections. 

Figure  2.  Tool  to  Organization  Interconnection  Profile 


Tool  to  Organization  Interconnection  Standard  Profile 
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is  tools  ere  interconnected  to  the  otgenizetions  diet  use  them,  tools  ere  interconnected  to 
the  platforms  where  they  operate.  A  platform  is  a  collection  of  hardware  and  software  com¬ 
ponents.  The  hardware  components  include  devices  such  as  central  processing  units,  disk  drives, 
printers,  and  displays.  The  software  components  Include  devices  such  as  operating  systems, 
database  systems,  communication  systems,  and  human  inteiface  systems.  A  tool  platform  may 
also  be  called  a  development  environment  or  an  operating  environment 

An  organization  may  use  only  one  platfoim  and  the  tool  will  be  operational  on  that  platform. 
However,  some  organizations  may  use  a  variety  of  platforms  and  platform  configurations,  in¬ 
cluding: 

1.  stand-alone  work-centers  (terminals,  woricstations,  and/or  personal-computers) 

2.  individual  work-cement  connected  to  a  central  host 

3.  individual  work-centers  Interconnected  through  communication  networks. 

This  variety  presents  two  issues  for  intercormecting  tools.  The  first  issue  is  the  ease  of  moving 
a  tool  from  one  platform  to  another  platform  -  portability.  The  second  issue  is  the  ease  of  using 
pbtfonn  services  to  allow  tools  to  exchange  information  within  a  platform  or  among  platforms 
-  connectability. 
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How  well  tools  interconnect  with  an  oisanizadon’s  available  platfonns  may  be  considered  bom 
the  following  perspectives: 

1.  Imerconnectiviiy  of  platfonns 

2.  distiibudon  of  tools  among  platfonns 

3.  oonfigumUon  of  individual  platfonns 

How  well  a  tool  interconnects  widi  a  specific  platfonn  may  be  considered  from  the  perspective 
of  how  the  tool  uses  the  standard,  available  jdatfoim  sen  ices,  and  nontrols: 

1.  operating  system  services:  access,  manipulate,  and  control  hardware  capabiliUes  for  all 
software  programs  on  a  platfomt 

2.  database  system  services:  store  and  retrieve  data,  text,  and  graphics  information  for  the 
application  software  programs  (axds)  on  a  platfonn 

3.  human  interface  system  services:  accept  and  display  data,  text,  and  gnqrhical  infor¬ 
mation  on  a  platfonn  for  the  human  u»er  of  an  application  program  (tool) 

4.  programming  language  systems:  generate,  control,  compile,  link,  load,  and  debug 
programs 

5.  comm'inication  system  services:  send,  receive,  encode,  decode,  and  route  information 
and  service  requests  between  applications  software  programs  (tools)  mnning  on  dif¬ 
ferent  platforms 

6.  dau  file  exchange  systems:  either  use  standard  file  fonnats  or  convert  ftom  proprietary 
fonnats  to  standard  file  fonnats 

7.  document  exchange  systems:  transfer  complete  documents 

The  productivity  and  effeedveness  of  a  tool  can  be  reduced  if  there  is  work  or  effon  involved 
in  moving  data  ftom  a  tool  on  one  platfonn  to  a  second  tool  on  a  different  platform. 

Attributes  of  %  well-defined  interface  specification  for  any  tool-to-platform  interconnection  are 
described  in  the  POSDC  (IEEE  P1(X)3.0)  system  architecture.  An  interface  specification  should 
be  open,  independent,  shared,  and  documented. 

1.  Open:  The  interface  has 

1.1.  the  cr^ability  of  allowing  a  user  or  iq}plication  operating  on  one  platform  to 
commuiticate  with  a  user  or  application  on  another  platform 

1.2.  documented,  nonproprietary  interface  specifications 

1.3.  standardized  ooimectivity  and  cmipling  for  each  mode  of  operation  with  im¬ 
plicit  responsibilities  to  preserve  imerfaces 

2.  Independent:  The  interface  supports 

2.1.  software  reuse,  fdatform  architecture,  and  application  internals 

2.2.  multiple  releases 

2.3.  recognized  authorized  usei:s 

2.4.  functional  recovery 

3.  Shared:  The  interface  is  designed  for  invocation  by  more  than  one  plication 

4.  Documented:  The  interface  has 

4.1.  well-ttefined  syntax,  semantics,  and  services 

4.2.  well-defined  set  of  parameters  invt^ng  equally  well-defined  sets  of  actions 
and  responses 
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3,3  Tool  10  pltlfbrm  inttreonnoctlon  tiandard  proflia 

Context  for  designing,  using,  or  testing  a  tool  is  established  by  the  platform  where  the  tool  will 
be  used.  One  step  toward  growing  kitowledge  of  the  context  is  to  identify  each  of  the  intercon* 
neoions  or  iclationships  between  a  tool  and  its  {datfonn.  The  'Tbol  to  Platform  Interconnection 
Stsndaid  Pmflle^  form  at  the  end  of  this  chapter  has  been  designed  to  help  identify  all  of  these 
interconnections. 

Figure  4.  Tool  to  Platform  Interconnection  Profile 
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4  Methods  for  Infomtatioii  Transfer  Among  Tools 

InlbnnaUon  tnuafer  among  tools  may  be  visuallxed  in  many  different  transfer  methods. 


Figure  5.  Example  InfwmaHon  Transfer  Methods 


Direct  (Put,  Get) 


TM  A 

1  1 

1  1 

FUe>Based  (Write,  Read) 


inMr 


Tcanr 


Repository-Based  (Store,  Retrieve)  Communicating  Systems  (Send,  Receive) 


Each  of  the  methods  serves  a  p&rticuiar  need  and  is  best  for  some  particular  simation.  The  direct 
transfer  method  is  the  most  efficient  from  a  response  time  perspective.  The  file  transfer  method 
is  best  fixHn  a  simplicity  of  hnplementaticn  perspective.  The  central  data  base  or  repository 
method  is  best  from  a  tools  integration  perspective.  An  in-memory  shared  woildng  area  method 
of  transfer  fits  somewhere  between  direct  and  repository>bascd  transfer  methods.  The  com¬ 
municating  system  method  is  best  from  an  open  systems  perspective.  If  the  communication 
systems  and  repositories  are  considered  to  be  tools,  then  all  of  there  informadon  transfer  methods 
may  be  rejMesented  with  a  standard  process  model  and  a  standard  inforciadon  model  as  illustrated 
in  Hgure  6. 

Tlie  next  two  chapters  of  this  standard  describe  information  transfer  among  tools  from  the 
perspectives  of 

1.  The  processes  of  information  transfer 

2.  The  information  transferred. 
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4.3  Descriptions  of  information  being  transforred 

If  information  is  to  be  oinsferted  among  tools  it  must  be  described  in  a  fonn  that  a  tool  can 
deal  with.  Each  increment  of  transferred  information  must  have  its  syntax  (form)  and  its  seman¬ 
tics  (meaning)  deflned. 

4J.1  Syntactic  (format)  information 

Syntactic  infonnation  describes  the  physical  structure  or  form  of  subject  informadon.  Syntactic 
information  may  or  may  not  be  transferred  among  tools,  but  it  will  be  used  in  the  sending  and 
receiving  processes.  ISO  8824  and  ISO  882S  provide  the  standards  necessary  for  defining  syn¬ 
tactic  informatioa  ISO  8824: 1987(E)  Information  processing  systems  -  Open  Systems  Intercon¬ 
nection  -  Specification  of  Abstract  Syntax  Notation  One  (ASN.l)  describes  the  notation 
recommended  by  this  standard.  ISO  8825:1987(E)  Infonnation  processing  systems  -  Open  Sys¬ 
tems  Intercormection  -  Specification  of  Basic  Encoding  Rules  for  ASN.l  describes  encoding 
rules  for  use  with  ASN.l.  Together  8824  and  8825  describe  the  following  infonnation: 

•  Atomic  dau  eiemerus  (bits)  and  how  those  atomic  data  elements  will  be  grouped 
for  interpretation  (coded)  into  primitive  Dataltems  such  as  characters  and  numbers. 

•  IIow  primitive  (unstructured)  Dataltems  may  be  grouped  together  into  structured 
Dataltems  such  as  words,  fields. 

•  The  delimiters  (characters,  symbols,  or  counts  of  characters)  that  separate  primi¬ 
tive  Dataltems. 

•  How  structured  Dataltems  may  be  grouped  together  to  fonn  Dataltems  of  larger 
structures  of  such  as  lists,  records,  files,  tables,  and  databases. 

432  Semantic  (meaning)  infonnation 

Semantic  information  is  the  information  that  represents  the  meaning  of  transferred  information. 
In  practice,  semantic  information  may  be  transferred  among  tools,  or  it  may  be  expressed  as  an 
agreement  among  the  tools  and  not  transferred  at  all.  Here  are  some  examples. 

•  The  concept  “process”  means  a  manipulation  or  derivation  of  data. 

•  The  concept  “fimctional  sute”  means  a  collection  of  one  or  more  operations. 

•  The  concept  “state  transition"  means  moving  from  one  state  to  arwther  state. 

•  The  concept  of  "data,  state”  means  the  characteristics  of  dau  at  an  instant  in  time. 
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5.  Semantic  Transfer  Language  (STL)  Overview 

This  chapter  contaUis  an  overview  of  the  STL  and  a  summary  of  its  syntactic  elements.  The 
STL  is  presented  in  top-down  order.  First,  a  complete  information  transfer  is  described.  Next, 
the  language  structures  are  described.  Finally,  the  language  primitives  arc  defined. 

5.1.  STL  Goals 

Design  decisions  for  the  STL  were  based  on  satisfying  the  following  goals,  in  OEder  of  decreasing 
priority: 

1.  The  STL  must  be  parsaMe.  This  goal  is  the  minimum  requirement  for  allowing  tool 
iruerconneaion.  If  information  is  to  be  transferred  amottg  tools,  the  tools  must  be  able 
to  read  the  information.  This  absolute  requirement  does  not  require  that  the  STL  be 
easy  to  parse,  only  that  It  be  parsable. 

2.  The  STL  must  be  easy  to  read  by  programmers  who  do  not  have  special  training  in 
the  STL  and  do  not  ttave  special  tools.  The  goal  is  to  express  information  about  software 
in  a  form  that  requires  the  least  amount  of  specialized  knowledge  to  read.  In  particular, 
a  software  description  written  in  the  STL.  should  be  readable  without  needing  a  special 
tool.  A  text  ediujr  should  be  sufficient  for  reading  an  STL  file. 

3.  The  STL  must  be  easy  to  write.  Programmers  who  have  limited  training  in  STL  and 
no  access  to  special  tools  must  be  able  to  write  a  description  in  STL  easily. 

4.  It  should  be  possible  to  conven  the  STL  iruo  a  compact  transfer  form  to  make  efficient 
use  of  machine  resources. 

Goals  2  and  3  imply  that  the  STL  should  be  a  language  that  is  close  to  natural  language.  Goal 
4  implies  that  the  STL  should  be  a  sparse,  machine-like  language.  To  meet  these  diverse  goals, 
the  STL  is  provided  in  a  human-readable,  highly  stylized  sentence  fomt. 

SJl.  STL  Sentence  Form 

Figure  7  contains  a  sequence  of  special  natural  language  sentences.  They  are  special  because 

1.  every  sentence  is  about  one,  and  only  one,  subjea  (ie..  Action  AOl). 

2.  every  sentence  contains  a  non-compound  vert  or  verb  phrase. 

3.  every  sentence  expresses  only  one  relation  to  or  attribute  of  the  subject 

4.  every  sentence  has  the  same  order  of  words: 

1.  a  subject  with  a  descriptor 

2.  a  verb  or  verb  phrase 

3.  a  direct  objea  with  a  descriptor  or  a  prepositional  or  an  adverbial  phrase 


t  Figure  8  contains  an  STL  sentence  that  contains  the  same  information  as  the  natural  language 

sentences  presented  in  Figure  7. 


Fisure  7.  Natural  Language  Sentences 

Figure  8.  STL  Sentence  Example  1 

1 

Actian  AOl  is  allowed  in  state  normal. 

Action  AOl 

is  allowed  in  state  nonnal : 

f 

Action  AOl  receives  eventiiem  wamiiig_inienupt 

Aciioo  AOl  tianmiiis  eventiiem  safety^acttonl. 

Action  AOl  uses  dauuiem  water.tempcnoure.ieadii^. 
Actian  AOl  produces  dauuiem  safety_acti(»i_rqx)rL 
Action  AOl  has  maximum  duration  time  3  seconds. 

receives  evendtem  waraing^tAtemipt ; 
transmits  event  safetyjactionl  ; 
uses  dautitem  waier.tempeiature.ieading ; 
produces  dataitem  safety  jictkm_ieport ; 
has  maximum  duration  time  3  : 
has  duration  time  imits  "secends*. 
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5.5.3.  STL_aauses 

in  ngure  1 1  the  fint  eiause  in  the  STL  example  sentence  describes  a  relation  between  Action 
AOl  and  noimal.  It  is  a  reladon.clause.  The  last  clause  in  tlie  example  sentence  describes 
one  measurable  fact  or  attribute  of  Action  AOl.  The  last  two  clauses  are  aaribute  clauses.  Each 
STL.clause  describes  either  one  relationship  for  or  one  attribute  of  the  subject  of  the  sentence 
where  the  clause  appears.  The  BNF  syntax  for  an  STL^ciause  is  described  as  follows: 

<STL^claus«>  ::*■  <r«l«tion_cl«us«>  I  <attrlbue«_clBU8*>  I  NULL 

Gauses  may  or  may  not  be  present.  When 
clauses  are  present,  they  may  appear  in  any 
order.  In  any  STL^sentence  a  partioilar  clause 
may  be  present  once  and  only  once. 

STL.dauses  must  begin  with  a  keypluase  and 
are  separated  by  a  semicolon.  The  last  clause 
in  a  sentence  is  properly  followed  by  a  period, 
not  a  semicoloa  However,  for  the  conveniotce 
of  sn.  users,  the  construct  is  allowed  at 
the  end  of  a  sentence  by  the  NULL  alternative 
above. 

5.SJ.1.  Relation_dauses 

A  rBlaiiion.dause  defines  a  relationship  between  the  system  or  software  concept  instance  being 
defined  in  the  STL.sentence  artd  one  or  more  concept  insumces  defined  in  other  STL.sentences. 
Reladon^dauses  may  describe  relations  such  as  abstraction,  aggregation,  connection,  presenta¬ 
tion.  and  restrictioa  The  set  of  relation_clauses  is  unique  for  each  pair  of  software  concepts,  so 
the  rdation.clauses  are  defined  with  the  STL.setttencss  in  Quqiter  6.  The  BNF  form  of  the 
relation^clause  i.s  as  follows: 

<r«lation_clause> 

<  r« la t ion^keywcsds > 

<relatlon_li8t> 

The  BNF  sentence  is  read  as  follows:  a  rela- 
tion_clause  is  defined  as  telation...keywords  fol¬ 
lowed  by  a  reUtlon_Ust.  In  Figure  12  the 
examine  STL  lenience  is  presemed  with  rda- 
tion.keywords  underlined  and  reladon.lists 
embolden^ 

The  last  word  in  each  set  of  relation^keywords  is  the  name  of  a  concept  whose  insLinces  can 
qipear  in  a  lelaiiorLlist  This  word  is  called  a  classifier.  The  classifier  allows  type  checking  and 
forward  referenditg  of  sentencejdentifieis. 

The  relatkm_list  references  (names)  the  concept  insumces  that  participate  in  the  rslationship. 
The  BNF  form  of  the  relation_li8t  is  as  follows: 

<r«JLation_li8t>  :  <r«latlon_nteinbttr>  {  ,  <r««latlon_ineniber>) 

<r«lation_nManb«e>  :  oentence  id«ntifl«r>  t  lEtD 


Figure  12.  STL  Sentence  Example  3 

AcuonAbl 

is  allowed  in  state  normal ; 
receives  eventitam  wamingJnteiTupt : 
transmits  eventitOT  safety  actionl  ; 
uses  dataitem  water_tcm|»erature_r(iading  : 
produces  dataitem  safety jicrion_rer*urt ;  | 

has  maximum  duradon  time  3  :  j 

has  doiaiion  time  units  "seconds". 


Figure  11.  STL  Sentence  Example  2 


Action  AOl 

is  allowed  in  state  noimal ; 
receives  eventiiem  waming_iniemipt ; 
transmiu  evendiem  safety.actionl  ; 
uses  dauiitem  water_:emperature_reading  ; 
produces  dataitem  safety.aciion.  report ; 
has  maximum  duration  time  3  : 
has  duration  time  units  "seconds". 
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6.  STL  Semantics:  Subject  and  Concept  Information 

This  Chapter  is  oifanized  as  follows:  Elections  6. 1  and  6.2  fonn  an  introductory  overview;  Section 
6.3  is  in  the  form  of  a  reference  handbook,  with  each  STL  concept  presented  in  alphabetical 
order. 

6.1.  STL  Concept  Organization 

SIL  concepts  are  logically  organized  according  to  subject,  purpose,  and  type.  This  logical  or¬ 
ganization  gives  a  classifleation  hierarcliy  with  three  levels.  The  classification  shows  the  com¬ 
monality  which  exists  among  the  concepts  and  the  differences  which  distinguish  between  them. 


The  classification  is  exhaustive,  and  the  distinctions  make  them  mutually  exclusive  as  well. 
Thus,  each  concept  fills  a  well-defined  information  transfer  need.  The  figure  below  illustrates 
the  dassificadon  hierarchy. 


Figure  14.  ClassIHcation  Hierarchy  for  Concepts 
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Canaant 

-  ralarartaa  namaa  for  Hitrala 

Oroaniman  Orawp 

Purpaaa:  uaar  foaua 

Callaetian 

•  graupinea  of  aafiwara  daaarfplion  alomants 

oaiaat 

.  aemMna  and  anadpamaia  propdtiiaa  and  tranaforma 

Imaga  Ovaap 

Purpaaa;  visual  praaantsdona  m  drawings 

OKapMaSymPal 

•  rafaranaaa  la  namsd  Imaga  Inataness 

Soflwaia  Bahavler  Catageiy 

SiAJoet:  oparMlono  of  oenwarp 

Data  Oraup 

«  labatrm  Inaianaaa  of  daiaiypaa  m  tranaforma 
•  Mamitlar  pro  party  tapraaatwailon 

OMBTIja 

•  p noparty  raprsaanatlow  aOaPaetlona 

-  prapany  aampanartt  strueturlng 

-  rwlaa  for  Intaraoden  inaiansa 

OataVlaw 

•  sndiy  auPlypa  siruetuta 

Tima  Oraup 

Purpaaa:  marfcino  af  lima 

•  labolad  appaaranaaa  of  meogrtisad  tima 

SwawOypa 

•  llina  nMsgnldon  abatraetlona 

Lagla  Oraup 

Purpaaa:  Oaelaiona 

ConM^prvulons 

•  pipparty  valua  inaianaa  diserfmlnaior 

CewaWati 

•  namatf  pro  party  valua  feiatanaa  diaerlmirwtora 

nanatarm  Oraup 

Purpaaa:  enangoa  of  pro  party  rapraaontaden 

OaMMora 

-  otwfviibl>  ahanQM  «f  praiMNtiM 
•  fViMIfkNI  of  (WOpOftlOO  bOtMPOOfI  ooOofio 

Oaupllna  Oraup 

Purpaaa:  prapagatlan  af  ohangoa 

•  mfomuHlon  prepagaior  ta  transfarme 

IvaluMaw  Oraup 

Purpaaa;  aaquanolng  of  alamgoa 

itaia 

*  otMfootoffflMflfi  onO  oonofoffii  oooooo 

itaiPirajralMpn 

•  allowad  ettangaa  of  ttaia 

This  classification  is  described  in  the  remaintter  of  this  section.  Appendix  A  contains  entity- 
relationship  diagrams  for  the  STL  which  illustrate  the  interrelationships  between  the  concepts. 
The  set  of  diagrams  is  organized  by  subtypes  and  interrelationships. 
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6.4.  STL  Summary 
6.4.1.  Keywords 

For  context-independent  parsing,  the  words  in  the  attribute  and  relation  clauses  are  reserved 
words  in  the  STL.  These  reserved  words  are  presented  in  the  figure  below,  in  alphabetical  order. 
ITicy  are  listed  with  the  label  ‘•keyword”  in  the  STL  Profile  (.see  Chapter  7). 


Figure  18.  STL  Keywords 
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6.4.2.  Attributes 

Several  attribute  clauses  are  present  in  more  than  one  concept  sentence  template.  These  clauses 
are  gathered  here  into  an  alphabetized  list  of  the  unique  occurrences. 


Figure  19.  STL  Attribute  Clauses 

hiMt  aetiofi  aftoot 

haa  eitfar 

haa  avanga  voiuma 

has  outar  eardinallty 

haa  eontant  tlmaatamp 

haa  plaeaholdar  value 

haa  eontant  varalon 

has  proeaas  method 

haa  oraator 

haa  purpose 

haa  erltieallty 

haa  ratantlon  tinw  unita 

has  ttaaertptlon 

has  ratriaval  affoet 

has  duration  time  unita 

has  siza  ranga 

haa  axpraaaion 

haa  standard  uaaga 

haa  axtamal  baala 

haa  subjaet 

haa  axtamal  uaaga 

haa  subtypo  rangaa 

haa  axtamal  valua 

has  tima  units 

haa  fixod  aizo 

has  tranafar  timing 

haa  flow  eharaetarlaUo 

has  transform  purpoaa 

haa  format 

has  units 

haa  Idontiflor  purpoao 

has  valua 

haa  Innar  eardinallty 

haa  valua  falsa 

haa  labol 

haa  value  rang* 

haa  maximum  bandwidth 

has  valua  trua 

haa  maximum  doiay 

haa  valua  unknown 

haa  maximum  duration  timo 

has  valuas 

has  maximum  ratantlon  tima 

has  voiumo  units 

has  maximum  voiumo 

is  aetlontypo 

haa  mamborahip  domain 

is  eonnaetientypo 

haa  minimum  bandwidth 

Is  datatypaolaaa 

has  minimum  dot«y 

la  evanttypaelaaa 

haa  minimum  duration  tima 

la  graphleaymboltypo 

haa  minimum  ratantlon  dm* 

la  statotransitlontype 

has  minimum  voiumo 

la  statatypo 

haa  null  oeeurraneas 

Is  valuatype 

has  oeeurraneas  for 

6.4.3.  Reciprocal  telations 

The  binary  relations  between  concept  instances  in  an  S„Packet  can  be  expressed  in  either  or 
both  directions.  Therefore,  each  relation  clause  has  a  reciprocal  relation  clause.  These  clause 
pain  are  ccdlected  here  and  oisanized  as  follows. 

•  The  unique  pain  of  concept  names  (CN1,CN2)  are  generated  as  those  pairs  of 
names  for  which  CN2  is  ^phabeticaJly  greater  than  or  equal  to  CNl. 

•  These  unique  pain  are  alphabetized  first  by  the  first  member  of  the  pair. 

•  Pain  having  the  same  first  member  are  alphabetized  by  the  second  member  of  the 
pair. 

•  The  reciprocal  relation  clauses  for  each  unique  pair  are  listed  bek>w  dre  pair  iden¬ 
tification  line. 

There  are  two  special  cases.  For  cemditiops,  the  defining  clause  “is  true  ir  takes  a  parenthesized, 
nested  logic  expression,  represented  below  as  “(CondExpression).”  That  expression  may  contain 
“component”  conditions,  but  there  is  no  exidicit  “has  component"  clause.  The  “is  component 
of*  clause  is  regarded  here  as  the  reciprocal  of  “is  true  if." 
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For  graptiicsymbols,  there  is  a  single  “pictures”  clause  used  to  relate  a  graphicsymbol  to  any 
concept  instance.  This  clause  is  represented  below  with  a  parenthetical  entry  for  the  intended 
sentence  identifier.  It  is  regarded  here  as  the  reciprocal  of  the  “is  pictured  with”  clause  in  the 
other  concept  templates 


Figure  20.  STL  Reciprocal  Relationships :  Actions 
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The  following  paragraphs  describe  the  derivation  of  the  STL  Profile. 

The  analysis  of  the  concept  sentence  templates  to  produce  the  Profile  is  illustrated  with  a 
simple  example.  Figure  21  contains  a  short  STL  sentence  template  example.  This  example  is 
fomied  from  the  Action  sentence  template  in  Section  6.3.1  by  ignoring  all  but  one  clause  in 
each  part  of  the  template.  A  partial  listing  of  STL  Profile  which  corresponds  to  this  example  is 
displayed  in  Figure  22. 


Figure  21.  STL  Sentence  Template  Example 

concept^nariM: 

Action 

c»ncept_meaning: 

a  transfonn  internal  or  external  to  the  subject  software, 
having  inputs  and  outputs  and  changing  states  of  action 
or  data  in  the  subject  software 

ccncept_text_presentation: 

senience.keyword: 

Action 

aeitiencejdentifier. 

ActionID 

1  possible.attributes: 

has  label 

labcl_string 

is  actiontype 

possible.relations: 

internal  j 
external 

usesdautitem 

DataltemlD  { ,  DataltemID } 

i  notes: 

1.  The  labeLstring  is 

a  stringValueShoit. 

tdditional.clauses: 

possibie.aoributes: 

for  actiontype  internal 

is  actiontype 

internal 

has  process  method 
possible.relations: 

method_description 

is  allowed  in  suue 

StatelD  { ,  StatelD  } 

additional.clauses: 

pt»sibie.attribuies: 

for  actiontype  external 

is  actiontype 
possible.relations: 
none 

external 

f 


The  initial  stqts  in  reducing  the  STL  sentence  templates  to  an  STL  profile  profile  ate  these. 

•  Identify  all  the  terms  needed  to  etqness  the  STL.  Identify  the  symbols  which  are  to 
represent  sentence  identifiers  such  as  “AcdonlD*’,  etc.  Identify  all  keywords  such  as 
“action",  “has",  “label",  “is",  “actiontype",  “internal",  etc.  Also,  identify  the 
mnemonics  for  the  value  types  to  appisar  in  an  instance  of  the  sentence  such  as 
“labeLstring"  for  a  “stringValueShort",  etc. 
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Diagram  A.2  STL  Concepts 
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Diagram  A.3  Software  Operation  Concepts 
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Diagram  A.4  Data  Concepts 
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Diagram  A.5  Event  Concepts 
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Diagram  A.6  Atction  Concepts 
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Diagram  A.7  ConnectlonPath  Concepts 
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Diagram  A.8  State  Concepts 
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Diagram  A,10  Object  Concepts 
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B.  Appendix  B:  STL  £ntity>Relationship  Diagram  Example 

(This  Appendix  is  ix)t  a  pan  of  IEEE  SiJ  1 175-19XX,  IEEE  Trial-Use  Standard  Reference  Model 
for  Computing  System  Tool  Interconnections,  but  it  included  for  information  only.) 

This  appendix  provides  an  example  of  the  STL  as  applied  to  an  entity-relationship  diagram. 

The  subject  is  Diagram  A.6.  Action  Concepts,  in  Appendix  A.  The  figure  is  repeated  here  for 
coi-vienoe. 

The  STL  text  here  is  actually  more  complete  than  the  diagram;  reciprocals  for  the  relationships 
are  included,  and  pan  of  the  entity  definition  for  Action  is  given. 

Diagram  B.1  STL  Entity-Relationship  Example 


365 


CIS  and  ATIS 

Eric  Black:  Atherton  Technologj- 

PRECIS  OF  PRESENTATION 

ATIS  is  an  IPSE  interface  specification  which  addresses  those  aspects  of  the  IPSE  which 
are  critical  to  the  tool  integrator  (or  implementor,  if  the  tool  is  designed  from  the  start  to  be  part 
of  the  IPSE).  Integration  of  a  tool  with  the  IPSE  (and  with  the  other  tools  which  are  already 
integrated)  involves  three  distinctly  different  yet  overlapping  aspects  of  integration; 

•  data  integration;  managing  the  tool’s  data  and  sharing  data  among  tools 

•  control  integration:  invoking  the  correct  tool  at  the  correct  time  and  in  the  correct 
way 

•  presentation  integration:  integrating  the  user  interface  of  the  tool  with  that  of  the 
IPSE  and  the  other  tools 

ATIS  focuses  primarily  on  data  integration,  but  treads  into  portions  of  control  integration  as  well. 
It  intentionally  does  not  address  presentation  integration  at  all.  It  requires  the  services  of  an 
underlying  data  repositoiy,  which  might  be  provided  by  an  Object-Oriented,  Entity-Relationship, 
Relational,  or  other  suitable  database,  but  does  not  at  present  specify  the  interface  to  that  service. 
In  terms  of  the  ECMA  Reference  Model  for  Engineering  Frameworks  (August  17,  1990),  ATIS 
addresses  the  Data  Repository,  Data  Integration,  Message,  and  Task  Management  Services. 

The  CASE  Integration  Services  (CIS)  committee  is  an  industry  consortium  of  hardware 
and  software  vendors  and  users  chartered  with  developing  or  adopting  a  set  of  standard  interfaces 
that  promote  the  integration  of  software  engineering  tools.  A  number  of  environment  interface 
specifications  are  being  or  will  be  evaluated  by  CIS,  including  ECMA  PCTTE,  CAIS-A,  IRDS, 
and  ATIS.  Related  work  being  observed  with  interest  includes  that  of  OMG,  OSF,  CFI,  CDIF, 
and  others. 

At  the  March  1991  ANSI  SPARC  meeting,  CIS  proposed  the  formation  of  a  Technical 
Committee  with  essentially  the  same  charter  as  CHS  (that  is,  to  adopt,  promote,  and/or  develop 
a  set  of  standard  interfaces  for  software  engineering  environments).  A  vote  is  to  be  taken  at  the 
July  SPARC  meeting,  and  a  positive  answer  is  expected. 

The  continuing  development  and  evolution  of  the  ATIS  specification  is  now  "owned"  by 
the  CIS  committee,  which  no  doubt  leads  to  further  confusion  over  the  difference  between  ATIS 
and  CIS.  The  distinction  is  quite  simple:  ATIS  is  a  specification,  CIS  is  a  committee. 

Because  there  have  been  multiple  versions  of  the  ATIS  specification  published  during  its 
evolution  to  date,  there  is  also  confusion  as  to  which  ATIS  is  the  "real"  ATIS.  The  current 
version  of  the  ATIS  specification  is  the  one  which  was  adopted  by  CIS  as  its  starting  basis,  and 
is  titled  the  "CIS  Base  Document  Vl.O".  It  is  available  from  the  CIS  committee  secretary. 
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An  earlier  special  version  of  ATIS  was  submitted  to  ANSI  IRDS  as  a  proposed  standard,  with 
numerous  additions  which  are  not  present  in  the  current  specification  (the  Base  Document).  It 
was  accepted  by  ANSI  IRDS,  yielding  the  document  titled  "ANSI  X3H4  Working  Draft:  IRDS 
ATIS":  it  was  later  rejected  by  ISO  IRDS,  and  is  no  longer  "active". 

There  is  some  overlap  between  ATIS  and  PCTE,  but  they  are  in  no  way  competing  or  in 
any  sense  interchangeable  speciflcadons.  PCTTE  is  primarily  interested  in  tool  portability,  and 
appears  to  have  an  operating  system  orientation.  ATIS  is  specifically  interested  in  tool 
integration  services,  and  assumes  that  conforming  environments  will  have  solved  the  portability 
problem  separately.  Thus,  ATIS  should  be  complementary  to  PCTE,  and  should  be  able  to  use 
PCTE  as  a  portable  basis  on  which  to  provide  tool  integration  services  within  a  development 
environment. 

For  the  most  part,  ATIS  represents  a  higher  level  of  services  than  does  PCTE.  However, 
it  is  not  possible  to  layer  ATIS  on  top  of  PCTE  as  the  two  specifications  stand  today.  The 
primary  reason  for  this  is  that  the  object  orientation  of  ATIS,  which  results  from  efforts  to  best 
satisfy  the  requirements  of  Ease  of  Extensibility,  Work  Flow  (Process)  Control,  Integrity 
Enforcement,  Data  Integration,  Customizability,  Reusability,  and  Security,  cannot  be  implemented 
"on  top  of  PCTE  if  so  doing  allows  direct  access  by  tools  to  the  PCHE  interfaces  without 
violating  those  requirements  (particularly  Integrity  Enforcement  and  Ease  of  Extensibility).  On 
the  other  hand,  if  ATIS  is  divided  into  two  portions,  a  low-level  object-oriented  model  and  high- 
level  IPSE  model,  and  if  the  services  provided  by  that  low-level  model  are  provided  by  PCHE 
as  its  evolution  continues,  then  the  fundanwntol  conflict  between  ATIS  and  PCTTE  would  seem 
to  disappear,  with  only  relatively  minor  specific  details  remaining  in  conflict.  Those  remaining 
conflicts  should  be  reconcilable  without  major  difficulty. 
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AXIS  /  CIS  /  Software  BackPlane: 
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There's  more  to  an  IPSE  than  just  tool  portability  and  tool  integration. 


Areas  of  Overlap: 
framework,  IPSE,  Populated  IPSE 
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Who  are  the  users  of  an  IPSE? 


IPSE  Requirements 
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Availability 


IPSE  Requirements  (cont*d) 
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Reusability 


AXIS  Semantic  Models 
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Toaster  +  Overlays 
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Integration  Dimensions 
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Enabling  Standards  and  Technologies 


•  PCTE  (OMS)  -  addressing  Data  Integration. 

•  HP  SoftBench  BMS  -  addressing  Control  Integration. 

•  OSF/Motif  -  addressing  User  Interface  Integration. 
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The  BMS  Satellite 
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A  BMS  Environment 


•  Tools  have  to  broadcast  relevant  messages; 

•  Tools  have  to  respond  and  react  to  appropriate  messages; 

•  Tools  are  automatically  started  when  a  request  is  made; 

•  The  BMS  is  low  cost: 

-  Easy  to  implement; 

-  Easy  to  modify  tools  to  use  it; 

-  Evolutionary  not  revolutionary. 
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How  does  the  PCTE  BMS  differ? 


•  BMS  is  implemented  entirely  upon  PCTE  (and  thus 
portable)  instead  of  UNIX; 

•  PCTE  message  queues  for  IPC  instead  of  sockets. 

•  PCTE  process  control  instead  of  UNIX  fork  and  exec. 

•  Messages  which  contain  the  working  schema  and  current 
reference  object  are  supported. 
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Implementation  Architecture 
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Our  Prototype  Tools 


•  Tool  Starter 

•  Monitor 

•  Development  Manager 

•  Graphical  Development  Manager 

•  Editor  ** 
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The  Prototype  Screendumps 
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Our  Experiences 


«  The  provjisioEi  of  data,  control  and  user  interface 
integration  from  a  PCTE  and  So^Bench  combination  is 
technically  feasible 

•  V/e  believe  that  tools  can  achieve  tight  integration  by  using 
data,  control  and  user  Itiierface  integration  support  from 
the  framework. 

•  PCTE  does  provide  help  for  the  tool  wrriter; 

•  PCTE  is  an  effective  portability  platform; 

•  designing  for  PCTE  and  SoftBench  is  good  engineering 
practice. 
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Summary 


Frameworks  can  provide  data,  control  and  user 
interface  integration. 

We  believe  that  a  PCT£  and  SoftBench  combination 
adds  value  to  PCT£  and  to  SoftBench. 

This  can  be  achieved  in  an  evolutionary  way. 
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Abstract 

The  PCTE  interfaces  provide  data-integration  services.  In  a  good  Software 
Engineering  Environment  (SEE),  however,  more  is  needed:  control  integration  to 
automatically  start  tools  and  share  services.  We  report  on  onr  intermediate  practical 
experience  of  adding  control  integration  to  PCTE.  More  precisely,  we  show  how 
Broadcast  Message  Services  can  be  layered  on  the  PCTE  platform  thus  forming  a 
SEE  framework  that  spans  the  tool  integration  dimensions. 

Keywords:  CASE,  Software  Engineering  Environments,  PCTE,  Soft- 
Bench. 

1  Introduction 

The  computer  support  environment  provided  for  software  engineering  today  typi¬ 
cally  consists  of  a  set  of  standalone  tools.  These  tools  are  monolithic.  These  tools  do 
not  usually  cooperate.  They  cannot  access  each  other’s  functionality.  They  have  no 
access  to  each  other’s  data  (and  would  not  be  able  to  understand  it  if  they  could). 
Their  user-interfaces  differ  widely. 

The  tools  are  monolithic  in  that  they  provide  many  of  the  services  more  naturally 
provided  by  the  framework  within  which  they  operate  or  by  other  tools.  For 
instance,  some  document  processing  tocds  today  offer  version  control  even  though 
it  is  also  provided  by  configuration  management  tools.  Such  tools  provide  so  much 
because  the  tool  providers  have  no  way  of  composing  tools  from  small  modular 
pieces. 

We  are  interested  in  how  the  framework  can  provide  different  types  of  compo¬ 
sition  or  integration  services.  These  integrating  services  would  help  tools  to  be 
•smaller,  more  modular  and  built  into  the  support  environment  as  needed  by  the 
software  enpneer. 

A  complete  support  environment  fm  software  en^eering  will  be  a  large,  complex 
system.  Nmther  the  high  level  of  financial  resourras  nor  the  wide  range  of  expertise 
required  to  provide  all  the  elements  at  a  support  environment  will  be  found  within 
a  ^^e  organisatioa.  The  use  of  open  standards  for  these  elements  is  an  essential 
enabling  frctor  for  the  production  of  quality  SEE  implementations. 
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.  W€  have  looked  at  two  techaologies  which  provide  elements  of  a  support  en- 
viroameot  and  investigated  how  they  might  be  combined.  The  technologies  are 
SoftBench  [2]  [4]  and  PCTE  [7]  [8]  (9]. 

SoftBench  is  a  product  of  Hewlett-Packard.  It  consists  of  an  integration  frame¬ 
work  and  an  integrated  set  of  tools. 

PCTE  stands  for  “a  basis  for  a  Portable  Common  Tools  Environment”.  PCTE 
defines  an  interface  to  support  -CASE  tools  and  development  environments.  PCTE 
itself  does  not  provide  any  tools:  it  is  a  framework  on  which  to  build  and  integrate 
tools.  The  development  of  the  interface  has  culminated  in  the  ECMA  PCTE 
abstract  specification  [9]  which  the  ECMA  general  assembly  adopted  as  an  ECMA 
standard  k  December  1990. 

We  have  undertaken  a  prototyping  activity  to  show  how  these  components  can  be 
combined.  The  goals  of  our  prototyping  activity  are  to  investigate  how  to  construct 
a  support  environment,  to  learn  how  to  use  it  and  to  examine  the  benefits  of  working 
with  it.  We  are  using  an  implementation  of  version  1.5  [7]  of  the  PCTE  interface  in 
our  prototyping  activities.  We  report  here  our  mtermediate  technical  results  from 
constructing  the  prototype  SEE  framework  in  the  HP  research  laboratories. 

2  Iiitegration  Services  in  an  SEE  Framework 

The  ECMA  CASE  environment  framework  reference  model  [1]  identifies  and  de¬ 
fines  ktegration  services  that  a  framework  may  provide  to  support  a  SEE,  and 
groups  related  integration  services  together.  Figure  1  shows  the  overall  structure 
of  the  reference  model  (this  is  an  conceptual  architecture  not  an  implementation 
architecture). 

The  reference  model  (RM)  can  be  used  to  categorise  the  services  offered  by  an 
SEE  framework.  Although  the  ECMA  RM  activity  was  spawned  from  the  ECMA 
PCTE  Standards  committee,  the  RM  is  completely  independent  of  PCTE.  The  RM 
can  be  used  to  position  standards  proposals  and  commercial  products,  and  helps  to 
understand  the  relationships  between  different  framework  offerings. 

This  section  quickly  sketches  the  services  required  d  an  SEE  framework  in  terms 
of  those  detailed  in  the  RM. 

The  RM  identifies  three  main  aspects  of  tod  integration: 

e  Data  Integration  (addressed  by  the  data  repository  plus  data  integration  ser¬ 
vices)  is  the  sharing  of  data  and  descriptions  of  that  data  (schemas)  between 
the  users  and  tools  of  the  support  environmeni. 

e  Control  Integration  (addressed  by  the  task  management  plus  the  message 
services)  is  the  management  of  cooperation  between  independently  developed 
tools  to  achieve  a  coordinated  effect. 

e  User  Interface  Integration  (addressed  by  the  user  interface  services)  is  a  com¬ 
mon  look  and  feel  for  tools. 

2.1  Data  Integration 

The  maintenance,  management,  and  naming  of  date  entities  or  objects  and  the 
relationships  among  them  is  the  general  pnrpoee  of  the  date  repository  services. 
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Figurt;  1:  Reference  Model  Structure 


Buie  lupport  for  process  execution  and  control  is  also  addressed  here  along  with  a 
location  service  to  support  physical  distribution  of  data  and  processes. 

The  data  integration  services  enhance  the  data  repository  services  by  providing 
higher-level  semantics  and  operations  with  which  to  handle  the  data  stored  in  the 
repository. 

2.2  Control  Integration 

A  high  level  of  control  integration  implies  that  a  tool  can  invoke  or  stimulate 
another  tool  to  perform  some  piece  of  the  software  process.  Control  integration 
is  governed  by  the  extent  to  which  a  tool  makes  it  possible  for  other  tools  to  invoke 
the  functionality  it  provides,  and  the  extent  to  which  the  tool  calls  other  tools  to 
communicate  changed  circumstances. 

The  message  services  aim  to  provide  a  standard  communication  service  that  can 
be  used  for  in^.er-tool  mid  inter-service  communication. 


2.3  User  Interface  Integration 

User  interface  services  are  required  by  all  applications.  Efforts  such  u  OSF/Motif 
provide  generic  services  which  are  suitable  for  SEEs. 

3  Enabling  Technologies 

The  application  of  the  RM  to  an  interface  definition  will  result  in  a  detailed  analysis 
of  w’hat  SEE  framework  services  are  covered  by  that  interface.  We  have  carried  out 
several  such  applications.  Included  among  these  are  the  application  of  the  RM  to 
PCTE  and  to  SoftBench. 

The  foUowing  important  points  result  from  positioning  PCTE  1.5  and  the  tool 
integration  component  of  HP’s  SoftBench  environment  against  the  RM: 

•  PCTE  covers  the  majority  of  the  data  integration  facilities; 

•  SoftBench  addresses  control  integration  via  its  Broadcut  Message  Server. 

•  SoftBench  addresses  user  interface  integration  via  OSF/Motif. 

SoftBench  treats  control  integration  u  an  orthogonal  issue  to  data  management. 
SoftBench  can  be  used  with  many  different  repositories.  We  ^ose  PCTE  because 
of  its  wide  coverage  of  data  management  facilities  and  because  it  is  a  standard  tool 
portability  platform. 

From  the  point  of  view  of  integration  technology,  SoftBench  and  PCTE  are 
complementary  and  add  value  to  one  another.  This  analysis  encouraged  ns  to 
investigate  the  combination  of  the  SoftBench  and  PCTE  Integration  technologies 
in  practice.  We  next  give  an  overview  of  each  of  SoftBench  and  PCTE  and  then 
describe  our  approach  to  combining  them. 

3.1  SoftBench 

The  SoftBench  environment  consists  of  a  set  of  integration  services  and  an  extensible 
set  of  tools  that  communicate  by  sending  and  receiving  messages.  Fbom  the  point 
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of  view  of  an  environmeot  builder,  SoftBench  consists  of  the  Broadetst  Message 
Server(BMS),  the  Execution  Manager  (EM),  the  user  interface,  support  for  distri¬ 
bution,  the  set  of  tools  and  the  Encapsulator.  The  BMS  and  the  Execution  Manager 
are  described  in  further  detali  by  Cagan  [2].  Further  information  about  SoftBench 
tools  can  be  found  in  Gerety’s  description  [4]. 

3.14  SoftBench  Integration  Services 

1.  SoftBench's  Broadcast  Message  Server  (BMS)  enables  executing  SoftBench 
tools  to  cooperate  in  supporting  a  software  engineer  to  carry  out  tasks.  Ex¬ 
ecuting  tools  in  SoftBench  send  a  message  to  the  BMS  when  they;  require 
a  service;  have  performed  an  action  that  may  be  of  importance  to  others;  or 
have  a  failure  to  report.  The  BMS  forwards  this  message  to  all  the  executing 
tools  that  have  registered  interest  in  a  “message-pattern”  that  the  message 
matches  (so  the  message  ^broadcast’  is  in  fact  selective).  Messages  can  be  sent 
to  the  BMS  by  tools  so  they  can  register  and  unragister  interest  in  patterns. 

2.  The  Execution  Manager  (EM)  in  SoftBench  keeps  track  of  the  tools  that  are 
executing.  The  execution  manager  cooperates  closely  with  the  BMS  so  that 
when  a  request  message  is  received  by  the  BMS,  the  EM  determines  whether  a 
new  tool  should  be  started  to  ser  vice  that  request  or  whether  the  request  can 
be  satisfactorally  handled  by  a  tool  that  is  already  running.  SoftBench  tools 
are  grouped  into  classes.  Difi^ering  criteria  can  be  applied  for  differing  classes 
of  tools.  A  class  is  a  cet  of  tools  that  provide  equivalent  services.  Example 
tool  classes  are  EDIT,  COMPILE,  or  DEBUG. 

3.  All  SoftBench  tools  have  a  common  look  and  feel  which  conforms  to  the 
OSF/Motif  [3]  standard. 

4.  SoftBench  is  designed  to  operate  over  a  distributed  network  of  workstations, 
and  offers  distributed  computing  support  of  three  kinds.  Firstly,  SoftBench 
can  start  tools  and  support  transparent  communications  between  tools  exe¬ 
cuting  on  remots  hosts.  Secondly,  SoftBench  tools  are  built  on  the  network 
transparent  X  Window  System  which  means  that  programs  can  run  on  one 
system  and  display  visually  on  another.  Thirdly,  SoftBench  supports  access 
to  remote  data. 

3.1.2  SoftBench  Tools 

The  initial  set  of  tools  delivered  with  the  SoftBench  product  concentrates  on  support 
for  developing,  versioning,  and  debugging  C  and  €4-+  programs.  An  increasing 
number  of  Encapsulated  tools  are  available  to  extend  the  core  environment,  for 
example  tools  for  configuration  management,  documentation,  structured  analysis 
and  structured  design,  and  testing. 

Some  fundamental  SoftBench  tools  of  particular  relevance  to  our  work  to  date 
are  the  Tool  Manager,  the  Message  Monitor  and  the  Development  Manager. 

•  The  Tool  Manager  presents  a  way  for  a  user  to  directly  mvoke  tools.  While 
this  Is  useful  at  the  start  of  a  work  session  the  user  wfil  later  take  advantage 
of  the  BMS  and  EM  support  for  control  integration.  The  user  will  normally 
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be  working  within  n  particular  tool  (inch  aa  a  debugger)  and  will  be  accessing 
the  functionality  of  other  tools  from  within  that  tool. 

•  The  Message  Monitor  displays  all  messages  that  get  sent  in  the  environment. 

«  The  Development  Manager  offers  a  view  of  the  underlying  file  system,  including 
an  indication  of  the  type  of  information  held  within  the  file  (e.g.  C  source  or 
build  information).  It  also  presents  a  set  of  operations  available  on  those 
files  (such  as  versioning).  The  set  of  operations  made  available  dynamically 
matches  the  type  of  the  file  (e.g.  it  is  not  possible  to  even  try  to  check-out  a 
non- versioned  hie). 

We  see  in  section  4.2.3  how  we  have  modified  these  tools  to  run  on  a  combined 
SoftBench  and  PCTE  framework. 

The  user  sees  tools  working  synchronously  because  cooperation  between  tools  can 
be  specified  and  the  SoftBench  system  supports  the  execution  of  that  cooperation. 
For  example,  should  the  user  change  the  source  code  of  a  program  while  working  in 
the  static  analysis  tool,  notification  of  those  changes  are  automatically  forwarded 
to  any  editor  working  on  the  source  file  for  that  code.  The  SoftBench  user  is  also 
presented  with  seamless  functionality  (synergy)  in  that  the  services  provided  by 
one  tool  appear  (to  the  user)  to  be  available  from  several  other  tools  also.  For 
example,  code  can  be  recompiled  through  a  user  request  to  the  debugger  (which 
is  automatically  forwarded  to  the  build  tool  via  the  BMS).  The  real  benefit  of 
SoftBench  to  a  software  developer  is  that  it  makes  available  these  adv’antages  of 
well-presented  control  integration. 

SoftBench  provides  a  further  tool  called  the  Encapsulator.  This  tool  enables 
existing  tools  to  be  integrated  into  the  SoftBench  support  environment  without 
source  code  modification.  It  enables  a  wrapper  to  be  developed  for  a  tool  so  that 
its  input  and  output  is  monitored.  Suitable  SoftBench  messages  can  then  be  sent 
and  acted  upon  by  the  encapsulated  tool,  and  a  SoftBench  user  interface  can  be 
developed  so  that  the  tool  looks  as  well  as  behaves  like  a  true  SoftBench  citizen 
(although  this  holds  for  a  particular  set  of  tools:  those  that  can  use  standard 
input /standard  output  and  that  can  be  decoupled  from  any  bitmapped  screen 
handling  they  do). 


3.2  PCTE  Integration  Services 

A  major  contribution  of  PCTE  is  its  Object  Management  System  (OMS),  designed 
to  meet  the  data  integration  needs  of  CASE  tools.  The  OMS  provides  the  ability 
to  model  relationships  between  data  objects,  by  supporting  a  variant  of  the  entity- 
relationship-attribute  data  model.  Object  management  facilities  indude  typing, 
schemas  and  transactions  to  support  data  structuring  and  data  sharing,  and  to 
maintain  data  integrity. 

PCTE  provides  a  complete  interface  for  the  tool  writer,  induding  process  man¬ 
agement  and  inter-process  communication.  PCTE  provides  synchronous  and  asyn¬ 
chronous  calling  of  processes  on  local  or  remote  hosts.  The  services  provided  are 
at  a  higher  level  of  abstraction  than  those  typically  provided  by  the  operating 
system.  PCTE  intcr-process  communication  services  are  provided  via  the  PCTE 
message  queue.  These  services  are  dosely  modelled  on  the  X/Open  System  V 
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Figure  2:  Prototype  Architecture 


UNIX^  interfaces.  These  services  are  also  at  a  higher  level  of  abstraction  than,  say, 
socket  based  communication  primitives. 

The  hardware  architecture  for  a  PCTE  system  is  a  network  of  bitmapped  work¬ 
stations  connected  by  a  high  speed  reliable  LAN.  PCTE  is  a  distributed  architecture, 
and  all  the  object  management  aord  process  management  facilities  are  transparently 
distributed. 

4  Prototyping  Experience 

In  this  section,  we  report  on  our  intermediate  restUts  from  building  a  prototype  SEE 
framework. 


4.1  Architecture 

The  architecture  of  the  prototype  is  shown  in  figure  2.  Because  PCTE  provides 
a  complete  interface  for  the  tool  writer  and  because  the  BMS  control  integration 
serives  are  at  a  higher  level  than  the  PCTE  facilities,  we  have  re-implemented  the 
BMS  on  top  of  PCTE. 

Each  of  the  boxes  shows  one  of  the  existing  components  from  which  we  con¬ 
structed  the  prototype.  The  arrows  from  the  tools  show  which  services  were  accessed 
by  the  tools.  Thus  the  tools  are  linked  in  with  and  make  rail*  to: 

1.  the  Motif  X  ^^^dow  libraries; 

2.  the  BMS  component  of  the  SoftBench  libraries; 

3.  the  PCTE  Ubraries. 


*UKIX  is  a  legisMtred  trademark  of  UNIX  System  Laboratories  Inc. 


It  can  be  seen  from  the  architecture  that  the  SoftBench  Tool  Inti$gration  Plat¬ 
form  only  provides  the  BMS  services.  We  are  investigating  extending  this  so  that 
tools  only  access  the  PCTE  services  through  this  intermediate  layer.  This  has  the 
ad^’antages  of  protecting  the  system  from  changes  in  successive  PCTE  versions  and 
minimising  the  task  of  providing  data  integration  iu  some  way  other  than  through 
the  PCTE  object  base.  It  wotild  also  mean  that  existing  SoftBench  tools  could  be 
ported  with  a  minimum  of  effort  to  the  combined  SoftBench/PCTE  framework. 

4.2  Description  of  the  prototype 

We  are  using  the  GIE  Emeraude  implementation  of  the  PCTE  1.5  specifications 
known  as  Emeraude  vl2.  It  is  a  complete  implementation  of  the  PCTE  1.5  interfaces 
with  additional  Common  Services  (e.g.  Metabase,  Version  Management). 

PCTE's  claim  to  provide  a  portability  platform  was  verified  by  us  when  we 
ported  several  thousand  lines  of  source  code  between  workstations  of  different  hard¬ 
ware  from  different  manufacturers. 

Figure  3  shows  some  of  the  elements  of  the  prototype.  The  top  box  represents 
the  BMS;  the  boxes  in  the  second  row  represent  class  managers;  the  boxes  in  the 
bottom  row  represent  instances  of  tools.  All  communication  is  via  the  BMS.  We 
now  describe  these  elements  in  more  detail. 

4.2.1  The  BMS 

The  BMS  runs  as  an  PCTE  process.  The  BMS  conununicates  with  all  the  tools 
through  the  PCTE  inter-process  communication  mechanism  of  message  queues. 
These  replace  the  socket  connections  in  the  SoftBench  BMS. 

The  BMS  has  an  associated  message  queue  whose  whereabouts  in  the  object  base 
must  be  known  by  all  tools.  The  message  queue’s  location  was  (arbitrarily)  chosen 
to  be  linked  to  the  static  context  of  the  BMS  (static  context  is  the  PCTE  term  for 
‘program’).  Essentially  the  BMS  maintains  a  ‘pattern  map’  which  is  a  map  from 
tool  identifiers  to  the  set  of  message-patterns  in  which  those  tools  have  registered 
interest.  It  continuously  reads  from  its  message  queue,  suspending  execution  until 
a  message  arrives.  The  message  will  be  forwarded  to  any  interested  tools  or  may 
cause  the  pattern  map  to  be  updated. 

4.2.2  The  Class  Managers 

Every  tool  belongs  to  a  class.  Each  class  defines  the  functionality  which  tools  of  that 
class  will  provide  to  other  tools.  This  functionality  is  accessed  by  sending  request 
messages  to  the  tool.  There  is  a  class  manager  for  each  class.  The  class  manner 
maintains  a  list  of  the  running  tools  of  its  class  and  carries  knowledge  of  whether 
there  is  a  tool  able  to  service  any  given  request  or  whether  a  new  tool  needs  to  be 
started. 

Each  class  xnanager  runs  as  a  PCTE  process.  They  each  have  an  associated 
message  queue  linked  to  their  static  context.  Each  class  manager  continuously 
reads  from  its  message  queue,  suspending  execution  until  a  message  arrives.  Any 
request  mess^  will  be  forwarded  to  whichever  tool  is  able  to  service  it.  All  class 
managers  are  very  similar  except  for  the  knowledge  about  when  new  tools  should 
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be  started  up.  This  knowledge  is  more  complicated  in  PCTE  where  objects  do  not 
have  unique  pathnames  and  where  the  context  of  a  tool  includes  the  working  schema 
of  that  tool. 

The  amalgamation  of  all  the  clacs  managers  corresponds  to  the  Execution  Man¬ 
ager  in  SoftBench.  By  separating  out  the  class  manager  processes  we  were  able  to 
make  the  decisions  about  whether  to  start  new  tools  to  handle  requests  specific  to 
the  class  of  the  tool.  In  SoftBench  the  Execution  Manager  used  the  UNIX  execution 
primitives.  In  our  prototype  these  have  been  replaced  with  the  PCTE  execution 
primitives. 

4.2.3  Tools 

A  number  of  simple  tools  have  been  put  tc^ether  for  this  prototype; 

•  The  INVOKE  tool  corresponds  to  the  SoftBench  Tool  Manager.  It  allows  the 
user  to  select,  start  and  stop  tools  of  any  of  the  available  tool  classes. 

•  The  MONITOR  tool  corresponds  to  the  SoftBench  Message  Monitor.  It 
registers  an  interest  in  all  kinds  of  messages  and  displays  them.  !t  provides  a 
window  onto  the  BMS  activities. 

•  The  DM  tool  corresponds  to  the  SoftBench  Development  Manager.  While  the 
SoftBench  development  manager  gives  an  interface  to  the  UNIX  file  system,  the 
DM  tool  gives  a  similar  interface  to  the  PCTE  object  base.  This  enables  us  to 
navigate  around  the  object  base.  The  tool  includes  some  version  management 
facilities  using  the  common  services  presided  with  the  Emeraude  product. 

•  the  DMGRAPH  tool  is  a  graphical  interface  tool  to  the  PCTE  object  base.  It 
navigates  the  object  base  via  mouse  selection  of  objects,  displays  the  object 
graph  to  a  user  chosen  depth,  reorientates  and  manipulates  the  graphical 
representation  and  dynamically  manipulates  working  schemas  to  provide  views 
on  the  object  b  .se. 

•  The  EDIT  tool  is  for  editing  the  contents  of  objects. 

Each  tool,  like  the  class  managers,  runs  as  a  PCTE  process.  They  each  have 
an  associated  message  queue  linked  to  their  static  context.  Each  tool  continuously 
reads  from  its  message  queue  (not  suspending  execution)  until  a  message  arrives. 
Any  request  message  will  be  serviced  in  a  tool  specific  way. 

4.2.4  Additional  PCTE  features  of  interest 

A  PCTE  installation  will  typically  be  distributed  over  a  set  of  workstations  con- 
nectad  by  a  local  area  network.  The  transparent  distribution  facilities  provided 
by  PCTE  meant  that  we  did  not  have  to  concern  ourselves  with  distribution  when 
designing  the  prototype.  We  believe  that  the  SoftBench  distribution  facilities  can  be 
provided  on  top  of  PCTE  with  the  added  advantage  of  location  transparent  access 
to  data. 

ECMA  PCTE  implementations  wiQ  provide  more  services  thsn  PCTE  1.5.  One 
such  service  is  the  ability  to  respond  to  events  such  as  access  to  particular  objects 
in  the  object  base.  Adding  such  services  to  our  existing  control  integrations  servicec 
are  of  much  interest  and  will  pmvidc  further  research  directions. 
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W«  h*v«  not  ut«d  th«  PCTE  nupport  Jbr  concurrency  &nd  integrity  control  and 
activities.  We  have  not  heavily  used  the  schema  management  facilities. 

6  Summary  of  What  V/e  have  Leaxnt 

Several  points  came  out  of  o,ur  construction  work  with  respect  to  PCTE: 

•  we  found  the  PCTE  interface  useful  ip  buildiPst  the  BUS  and  the  ptototype 
tools,  ft  provided  all  the  facilities  we  n^ded  and  many  of  the  servlcus  v/ere  at 
a  higher  level  than  that  proviilad  by  the  operating  system. 

•  PCTE  is  Ui  effective  portability  platfonr.; 

•  we  found  object  identification  eomv'what  cenfusing,  Having  to  switch  between 
pathnames,  internal  references,  external  references  and  volume  number,  object 
number  pairs.  A  clear  notion  of  object  surrogate  would  have  simplified  our 
task. 

•  documantation  is  needed  to  guide  the  tool  writer  through  the  many  design 
decisions  he  needs  to  make.  This  should  indude  a  guide  for  data  integration 
(bow  to  use  the  schemas  provided  aid  how  to  write  new  ones,  etc.),  and  a 
guide  for  control  integration  (bow  to  use  the  interfaces  exported  by  existing 
tools  and  what  new  message  interface  a  tool  should  provide,  etc.)  ; 

t  a  cloar  and  well  documented  migration  path  from  existing  toolsets  will  be 
needed; 

•  The  distribution  fadlities  provided  by  PCTE  meant  that  we  did  not  have  to 
concern  ourselves  with  distribution  issues  when  designing  the  prototype. 

There  m  many  software  architecture  decisions  which  should  be  made  by  tool 
writers  even  if  PCTE  is  not  used  as  the  basis  for  the  support  environment  (such  as 
the  production  of  appropriate  schemas  aud  the  use  of  integrating  service  libraries 
which  hide  the  underlying  technology).  These  are  generally  |}ood  engineering  prac¬ 
tices  but  will  protect  investment  ic  tods  and  will  ease  the  transition  to  PCTE. 

The  prototyping  work  at  HP  Laboratories  has  proven  the  feasibility  of  adding 
a  BMS  to  PCTE.  We  are  starting  a  new  prototyping  phase  to  experiment  with 
rehosting  the  SoftBench  environment  on  PCTE. 
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1.  A  type  model  to  specify  values  communicated  between 

modules. 

2.  A  set  of  control  paradigms. 

3.  A  set  of  communication  promises  that  the  bus  will  ensure. 

4.  Linguistic  means  to  define  a  module’s  interface. 

5.  Linguistic  means  to  define  the  representation  of  values  of 

each  type  that  the  bus  may  transfer. 

6.  Linguistic  means  to  specify  valid  communication  patterns', 

such  a  specification  is  termed  a  configuration. 

7.  Language  bindings  that  map  each  language  type  into  a  bus 

representation  and  language  control  constructs 
into  bus  control  paradigms;  each  such  language  is 
termed  a  target  language. 
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configuration  and  module  interfaces. 
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and  runtime  libraries. 


485 


Information  Resource  Dictionary  Systems 

Data  Dictionary  Systems  have  existed  in  the  data  processing  industry  for  a  number  of 
years.  These  systems  have  generally  been  used  to  capture  and  store  definitions  of  data  and  files. 
In  recent  years  the  scope  of  dictionaries  has  expended  to  include  a  variety  of  other  information 
resources.  As  a  result,  these  systems  are  now  called  Information  Resource  Dictionary  Systems 
rather  than  Data  Dictionary  Systems  to  reflect  their  expanded  scope.  However,  the  reason  for 
implementing  these  systems  remains  the  same: 

•  Provide  effective  control  over  information  resources; 

•  Assure  adequate  documentation; 

•  Provide  standards  for  achieving  consistency  across  applications;  and 

•  Provide  configuration  management  and  traceability  over  time. 

For  example,  an  IRDS  can  help  achieve  standardization  when  gathering  requirements  for  a  new 
system  which  is  to  be  built.  The  IRDS  can  provide  the  vocabulary  to  used  between  the 
systems  analyst  and  the  end-user.  Adherence  to  a  commonly  understood  and  generally  agreed 
upon  terminology  will  contribute  substantially  to  assuring  that  the  statement  of  requirements 
reflects  the  true  needs  of  the  end-user  and  the  enterprise.  Equally,  for  data  elements  which  are 
shared  by  different  users  and  perhaps  different  organizational  components,  availability  of 
commonly  agreed  upon  definitions  of  data  elements  will  help  in  clearing  up  misunderstandings 
of  terminology  or,  even  more  importantly,  may  prevent  such  misunderstandings  from  occurring. 

An  IRDS  can  provide  a  powerful  tool  for  Information  Resource  Management.  One  of  the 
problems  that  is  encountered  in  IRM  is  the  vast  amount  of  data  about  information  resources  that 
is  required  to  manage  them,  together  with  the  very  complex  and  numerous  relationships  that  exist 
among  them.  This  is  precisely  the  sort  of  task  that  an  IRDS  can  be  made  to  do,  provided  that 
it  has  been  conditioned  to  know  how  to  deal  not  just  with  data  entities  or  process  entities,  but 
with  the  entire  gamut  of  information  resource  entities. 

In  order  to  accomplish  these  broader  objectives,  facilities  will  be  needed  that  go  well 
beyond  those  available  in  existing  data  dictionary  systems.  These  include; 

•  Extensibility, 

•  Flexibility, 

•  Version  Management,  and 

•  Life  cycle  Phase  control. 
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Extensibility 


When  dictionaries  focused  only  on  data,  most  installations  could  operate  using  the  same 
dictionary  structure.  However,  as  the  role  of  the  dictionary  system  expands,  it  is  more  and  more 
likely  that  different  installations  will  want  to  store  different  information.  Accordingly,  IRDS’s 
must  allow  each  installation  to  extend  the  types  of  information  that  are  stored  in  the  IRDS. 

Extended  types  defined  by  the  user  must  be  subject  to  the  same  controls  as  any  types  that 
are  defined  by  the  dictionary  vendor.  All  facilities  of  the  dictionary  must  apply  equally  to  vendor 
supplied  data  and  the  extensions.  There  can  be  no  distinction. 

The  architecture  of  an  IRDS  must  be  designed  form  the  outset  to  be  extensible.  Not 
surprisingly,  this  was  a  major  goal  of  the  ANSI  and  FIPS  IRDS  standard. 


Flexibility 

An  IRDS  must  be  suitable  for  a  wide  variety  of  uses.  The  interfaces  to  the  IRDS  must 
be  flexible  enough  to  deal  with  the  extended  infomiation  types.  Users  must  also  be  able  to 
access  IRDS  data  on  their  own.  However,  the  controls  inherent  in  the  IRDS  must  be  maintained. 


Version  Management 

An  IRDS  must  be  able  to  maintain  and  manage  multiple  versions  of  an  entity  in  a 
consistent  way.  Version  maintenance  cannot  be  left  to  each  application  or  user,  but  must  be  an 
integral  pan  of  the  IRDS. 


Life  cycle  Phase  control 

As  entities  in  the  dictionary  move  through  their  life  cycles  they  should  be  subject  to 
different  sets  of  constraints.  When  an  entity  represents  a  component  of  a  product  that  is  in  the 
early  stages  of  development,  it  may  be  subject  to  fairly  loose  control.  However,  when  a  system 
or  building  or  piece  of  electronic  equipment  goes  into  "production"  the  controls  must  be  very 
tight.  The  IRDS  needs  to  be  able  to  track  entities  through  life  cycle  phases  and  to  enforce 
different  levels  of  control  during  different  phases. 


IRDS  Standardization 

Standards  committees  are  not  formed  to  do  basic  research.  That  is,  they  are  not  allowed 
to  invent  something  out  of  thin  air  and  standardize  it.  Instead,  the  job  of  a  standards  organization 
is  to  examine  existing  products  in  a  relatively  mature  industry  and  to  develop  a  standard  based 
on  those  existing  products.  The  development  of  the  IRDS  Standard  was  no  different. 
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Two  design  objectives  for  the  IRDS  Standard  were  defined  at  the  outset.  First,  the  IRDS 
Standard  must  contain  the  major  features  and  capabilities  that  are  provided  by  existing 
commercial  dictionary  systems.  At  the  same  time,  it  must  provide  the  power  and  flexibility 
needed  to  support  the  next  generation  of  Information  Resoiu'ce  Management. 

The  second  objective  was  that  the  standard  should  be  modular  to  allow  it  to  be 
implemented  in  a  wide  variety  of  environments.  If  the  standards  required  every  conceivable 
feature  to  be  implemented  in  order  for  a  dictionary  system  to  be  declared  conformant,  it  might 
be  impossible  for  conformant  implementations  of  the  standard  to  run  on  smaller  machines.  Thus, 
the  standard  defines  a  set  of  minimal  functionality,  called  the  "Core  Standard"  or  "Module  I",  and 
a  set  of  optional  "modules"  that  define  additional  functionality  that  can  be  added  by  the 
implementor  when  appropriate  for  the  particular  target  environment.  There  are  currently  five 
optional  modules. 

In  1980,  two  organizations  began  independently  to  develop  a  standard  for  dictionary 
systems  in  the  U.S.  The  National  Bureau  of  Standards  (NBS,  now  renamed  NIST)  began  an 
effon  to  develop  a  Federal  Information  Processing  Standard  (FIPS)  that  was  called  the  "Federal 
Information  Processing  Standard  for  Data  Dictionary  Systems".  The  American  National 
Standards  Institute  began  a  similar  effort  with  the  approval  by  the  American  National  Standards 
Committee  for  Information  Systems  (X3)  of  what  is  now  called  the  Accredited  Standards 
Committee  (ASC)  X3H4.  Their  charter  was  to  develop  an  American  National  Standard  for 
"Information  Resource  Dictionary  Systems". 

These  efforts  continued  independently  until  1983  when  X3H4  voted  to  adopt  the  current 
draft  version  of  the  FIPS  standard  as  its  base  document  for  all  subsequent  work.  From  1983- 
1988,  X3H4  atid  NIST  worked  together  to  develop  the  draft  proposed  American  National 
Standard  for  Information  Resource  Dictionary  Systems  (dpANS  IRDS). 

During  that  time,  dpANS  IRDS  was  given  two  formal  public  reviews.  The  first  one  was 
in  1985  and  it  resulted  in  such  extensive  revisions  that  a  second  public  review  had  to  be 
performed  in  1986.  Only  minor  revisions  were  required  as  a  result  of  the  second  review  and,  on 
October  19,  1988,  the  dpANS  IRDS  became  an  official  American  National  Standard.  This 
standard  covers  the  functionality  of  an  IRDS  and  deHnes  Panel  and  Command  Language 
interfaces  to  the  IRDS. 

On  April  5, 1989,  the  National  Institute  of  Standards  and  Technology  announced  the  FIPS 
standard.  Other  than  a  minor  change  in  the  conformance  statement,  this  standard  is  identical  to 
the  ANSI  standard.  This  standard  became  effective  for  U.S.  Government  Agencies  on  September 
25,  1989.  However,  there  was  an  additional  eighteen  month  "transition  period"  during  which 
U.S.  Government  Agencies  could  continue  to  get  waivers  to  allow  them  to  purchase  dictionary 
systems  that  were  not  compliant  with  the  FIPS.  Thus,  the  FIPS  did  not  become  mandatory  until 
March  25,  1991. 
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Information  Resource 
Dictionary  System 


E.  James  Emerson 
Repository  Technologies,  Inc. 
3590  Hobson  Road,  Suite  204 
Woodridge,  IL  60517 
(708)  515-0780 
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Topics 


•  Dictionary  System  Concepts 

•  History  of  the  IRDS  Standard 

•  Overview  of  the  IRDS  Standard 


Webster's 


New  World 


Dictionary 


OF  THE  AMERICAN  LANGUAGE 


OVCR  SI, 000  (NTRtCS 
LARCe,  eASV*TO<RIAO  TYPE 
OVER  200  illustrations 


OVER  It, 000, 000  COPIES  IN  PRINT 
■ASEO  ON  THE  SECOND  COLLEGE  EDITION  OP  WEBSTER'S 
NEW  WORLD  dictionary  OP  THE  AMERICAN  LANGUAGE 

POPULAR  LIBRARY  PAPERBACK  EDITION 


System 


Another  Type  of 
Dictionary  System 


IRDS  Services  Interface 


Applications  and  Data 


An  application  automates 
a  business  function 
for  the  corporation. 

A  DBMS  manages  the 
data  that  describes  the 
corporation's  business 
resources. 


Each  "record"  describes 
a  real  employee 
(a  corporate  resource). 
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System  Development  Tools 
AND  Meta- Data 


A  systems  development 
tool  automates  a  systems 
development  function  for 
the  data  processing  organ¬ 
ization  within  the  corporation. 

An  IRDS  manages  the 
meta-data  that  describes  the 
corporation's  information 
resources. 


Each  "record"  describes 
a  real  information  resource 
(e.g.  program  or  data  base) 
which  are  also  corporate 
resources. 
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What  is  an  IRDS 


An  IRDS  as  a  special  purpose  DBMS  used  by 
systems  development  and  systems 
management  tools  for  storage  and 
maintenance  of  meta-data  that  describe  a 
corporation's  information  resources. 


Why  an  IRDS? 


•  Provide  consistency  of  Meta-Data 

•  Facilitate  reuse  of  data  elements  and  programs 

•  Identify  all  the  components  that  comprise  an 
application  system  (Configuration  Management) 

•  Determine  the  overall  impact  of  a  change  to  a 
particular  component  of  an  application  system 
(Change  Management) 

•  Provide  a  means  to  integrate  application 
development  and  systems  management  tools  from 
different  vendors 


History  of  the  IRDS  Standard 

1980 

Committee  Formed 

1983 

Base  Document  Adopted 

1984-1985 

Vendor  Workshops 

1985-1986 

Public  Review 

October  19,  1988 

ANSI  IRDS  Standard  Adopted 
ANSI  X3.1 38-1 988 

April  5,  1989 

NIST  IRDS  Standard  Adopted 
FIPS  PUB  156 

September  25,  1 989 

NIST  Standard  Effective  Date 

March  25,  1991 

End  of  Transition  Period 

-  9  - 
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ISO  IRDS 


•  Base  document  adopted  by  IRDS  Rapporteur  Group 
in  1986 

•  Interest  is  in  Services  Interface  only 

•  Was  compliant  with  ANSI  IRDS  of  a  short  period 

•  Data  model  changed  from  entity-relationship  to 
object-association 

•  Attempt  at  cooperation  delayed  final  approval  of 
ANSI  IRDS  Standard 

•  IRDS  Rapporteur  Group  is  now  moving  towards 
pure  SQL  approach 


IBM  Repository  Manager/MVS 


•  IBM  has  submitted  an  alternative  Services  Interface 
to  ANSI  and  ISO 

•  Ai  ernative  is  based  on  Entity-Relationship  Tools 
Interface 

•  IBM  may  submit  proposal  for  Object  Service  Tools 
interface  in  the  future 

•  The  Repository  will  become  the  de  facto  standard 
for  SAA 


- 11  - 
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DEC  ATIS 


•  DEC  has  submitted  ATIS  as  a  proposed  IRDS 
interface  to  ANSI  and  ISO 

•  Within  ANSI,  proposal  is  for  a  next-generation 
standard 

•  Current  standard  is  treated  as  a  subset 

•  X3H4  adopted  proposal  as  a  base  document  for 
"IRDS  Support  of  CASE" 

•  X3H4  recommended  proposal  as  new  work  item 
within  ISO 


ANSI  IRDS  Features 


•  Command  Language  Syntax  and  Semantics 

•  Menu-driven  Panel  Interface  Semantics 

•  Fully  Extensible 

•  Maintain  Multiple  Versions 

•  Life  Cycle  Phase  Control 

•  Security 

•  IRD  Views 

•  Impact  of  Change  and  Other  Reports 
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IRDS  Architecture 


Defined  By 
IRDS  Implementor 


Defined  By 
IRDS  Standard 
and 

IRDS  Implementor 


Defined  By 
IRDS  Standard, 
IRDS  Implementor, 
and 

IRDS  Administrator 


Defined  By 
Data  Processing 
Organization 


Describes 
&  Controls 


Describes 
&  Controls 


Information 

Resources 


Describes 
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Extensibility 


•  Standard  specifies  a  "Starter  Set"  IRD  Schema. 

•  Users  are  expected  to  extend  this  to  satisfy  their 
requirements. 

•  Extensions  are  defined  by  Entity  Types, 
Relationship  Types,  and  Attribute  Types  in  the  IRD 
Schema. 

•  There  is  no  distinction  between  starter  set  and 
extensions.  Starter  set  can  be  deleted  if  desired. 


Some  Components  of  a 
Typical  IRDS  Schema 


IRDS  Applications 


•  Maintain  meta-data  throughout  the  development 
life  cycle,  including  operational  phase 

•  Support  data  element  standardization  program 

•  Manage  schema  and  sub-schema  definition  for  a 
DBMS 

•  Support  records,  report,  and  forms  management 
programs 


-  17  - 
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Future  Directions 


•  Establish  standards  for  the  representation  of  meta¬ 
data  In  the  IRDS 

•  Establish  standard  methodologies  for  Configuration 
Management  and  Change  Management 

•  Vendors  provide  tools  that  maintain  meta-data  in 
the  IRDS 

•  ANSI  and/or  ISO  adopt  a  "next  generation" 
standard 


-  18  - 
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Reference  Model  Improvements 

•  Service  descriptions 
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SEMATECH’s  Advanced  Development  Environment 
Claude  Baudoin 


SEMATECH  is  a  consortium  of  14  U.S.  companies  which  are  either  semiconductor 
manufacturers,  or  computer  companies  with  their  own  chip-making  operations.  The 
consortium  performs  pre-cornpetitive  research  on  advanced  manufacturing  techniques  and 
equipment.  It  is  funded  by  D/\RPA  for  50%  of  its  $200M  yearly  budget,  and  by  its  member 
companies  for  the  other  half. 

CIM  (Computer-Integrated  Manufacturing)  is  increasingly  being  recognized  as  one  of  the 
major  challenges  for  effective  manufacturing.  SEMATECH  has  created  a  CIM  Architecture 
which  defines  several  Ir  ''ers: 

-  applications 

-  a  generic  semiconductor  manufacturing  model 

-  a  development  environment 

-  an  execution  environment 

The  Advanced  Development  Environment  (ADE)  project  is  a  key  part  of  how  we  intend  to 
improve  the  quality  and  accelerate  the  emergence  of  new,  model-driven  manufacturing 
applications.  The  project’s  deliverables  are  created  by  a  working  group  of  member  company 
representatives,  created  in  Deceml  '.r  1990,  which  has: 

defined  the  requirements  for  a  CASE  framework, 

performed  an  extensive  evaluation  of  several  coirmercial  frameworks, 

started  writing  an  "Analysis  and  Desigi^  Guide,"  a  set  of  life  cycle  guidelines  for  CIM 
applications  based  on  object-oriented  techniques, 

developed  a  plan  and  lined  up  resources  for  education  and  technology  transfer 

In  the  framework  area,  SEMATECH’s  CIM  Architecture  concept  of  an  "integrated  model 
repository"  containing  various  models  which  can  drive  the  execution  of  CIM  applicatioas 
means  that  the  presence  of  a  data  integration  component  is  considered  a  key  requirement. 
This  and  other  aspects  of  the  program  relevant  to  the  PQS  Workshop  will  be  presented. 
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SEMATECH  Advanced  Development  Environment 
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Texas  Instniments 


CIM  APPLICATIONS  ARCHITECTURE  (CAA) 
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Execution  environment  is  dependent  on  the  modeling  environment  for  its 
operation.  As  the  models  change,  the  application  changes. 


ARCHITECTURAL  VISION  FOR  FUTURE  MANUFACTURING  SYSTEMS 


SEMATECH  Advanced  Development  Environment 


566 


567 


CO 


s 


c 

2 

S 

2 

CL 


•  • 
£ 


568 


Intriguing  possibilities  to  be  explored  in  manufacturing  world: 

-  extend  the  repository  to  manufacturing  information 

-  extend  process  management  to  cover  the  manufacturing  process 


569 


Constraints 


r 


571 


SEMATECH  Advanced  DeyeSopment  Environment 
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SEMATECH  Advanced  Development  Environment 
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Environments  —  An  Industry  View 
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What’s  MCC  doing  In  environments?”  [coiket] 
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Environments  industry  “Food  Chain 


PCIS  2  Workshop _ -  4  - _ June  4. 1991 


Some  Environment-Related  MCC  Projects 
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Enterprise  Integration  Conceptual  Architecture 

Filling  in  the  Gap 
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Enterprise  Integration  Conceptual  Architecture 

Fundamental  Concepts  -  Change  Control  &  Events 
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EnterprisG  Integration  Conceptual  Architecture 

Integrating  the  Enterprise 


3 

Enterprise  Modeling 
(Together  with  Pacific  Bell  Comp.) 


Specifying  in  a  consistent  way,  the  details  of  an  information 
system  required  for  the  support  of  some  business.  The  POS 
methodology  maps  these  dimensions  into  a  set  of  £-R  descrip¬ 
tions  from  which  they  are  mapped  into  CDC, 

Example:  The  N695  Motor  Vehicle  Registration  Authority 

•  Objects:  Cars,  Trucks,  Engines,  etc. 

•  Processes:  Transferring  ownership  from  one  legal  owner  to 
another. 

•  Constraints:  **A  Vehicle  must  be  owned  by  n  legal  owners 
0  <  n  <  4” 


PCIS  2  Workshop 
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Coordination  Theory  &  Technoiogy  Project  mcc  Software  Technology  Program 

Research  Goal: 

^  Develop  a  software  system  to  support  coordination 
among  people,  tasks,  and  resources  in  an 
organization.  The  system  will 
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enforcement  and  dynamic  change 
Adaptable  to  particular  organizational  practices 
Integrated  with  existing  tools  &  methods 
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Block  Architecture  of  Coordination  Env. 
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and  Cemputar  Tachnology  Corperallcvt 
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Carnot  Project  Goals  for 

Enterprise  Information  Integration 
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Carnot  Architecture 
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Concurrmt  T^r^cution  of  OBjzcts 


Distributed  Execution;  What  makes  it 
possible  ? 


overloaded  method  invocation 


RexnpteBase :  :  opera'tor'-‘>  ( ) 
en^loyee*  John^Doa; 

naw^salary  =  John_JDoe->ra±se  (more)  ; 


extended  obiect  creation 


Jolixi^Doe  =  new  {remotie}  employee  ()  ; 


Jiitures  for  multi-threaded 
_ execution 


future  £; 


f  +»  Tax->conput«_t*3c(salaty)  ; 

^  rinajica^^Gon^Tita  IsanafiL't  (salaz^)  ; 
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What  Aerospace  has  currently  got. 
Organisation  Management 
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What  Aerospace  has  currently  got. 
Integrated  Team  Working 
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European  Aerospace  User  Requirements 
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What  Aerospace  needs  in  the  future 
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PCIS  -  Environment  Users 


What  Aerospace  is  doing  about  their  needs 
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What  Aerospace  is  doing  -  AIMS 
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Aerospatiale,  Alenia,  British  Aerospace 
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What  Aerospace  is  doing  -  AIMS 


European  Aerospace  Evaluations 
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ECS  Development  Model  is  a  basis  for: 
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Review  of  Environment  Users  Ses¬ 
sion 

1.  Review  of  Session  Objectives 

2.  Overview  of  the  London  Workshop  and  Result¬ 
ing  Requirements 

3.  Individual  Requirements  Presentations: 

Vic  Stenning  :  Process  driven  requirements, 
evolution  and  lego  interfaces 

John  Leary  :  Role-based  requirements  analysis 

Judy  Kerner :  Needs  for  PCIS  Administrative 
Services 

Claude  Baudoin  :  The  Requirements  process; 
technology  push  vs.  user  pull 

Robert  Rankin  (for  Morron)  Stability,  Systems 
Engineering  and  Benefits 

Audrey  Canning  :  Identifying  Methods  and 
Tools 

4.  Mass  Confusion,  DISCUSSIONS 

5.  Formulate  Areas  of  Requirements 

6.  Breakouts  to  Refine  Requirements 
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Resulting  User  Requirements 


1 .  Requirements  on  the  PCIS  Process 

Introducing  Change 
Activities  and  Products 

2.  Requirements  on  the  PCIS  Products 
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Business  Drivers 


The  programme  will  be  successful  only  if  it  stimu¬ 
lates  considerable  investment  (and  therefore 
buy-in)  in  PCIS  results  from  the  user  as  well  as 
vendor  communities 


Users  are  aiming  for  quality,  productivity  and  cost 
improvements  -  with  acceptable  risks 

These  are  achieved  via  improvements  to  the  pro¬ 
cess 


An  integral  part  of  this  is  environment  improvement 


The  PCIS  program  must  view  itself  as  introducing 
change 
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lntroducin(;i  Change 


The  PCIS  programme  should  identify  the  specific 
user  problems  that  it  aims  to  address,  and 
should  show  how  its  products  can  be  deployed 
by  users  to  overcome  those  problems 


The  PCIS  programme  must  involve  continual  user 
participation,  and  must  respond  to  user  feed¬ 
back 


The  PCIS  requirements  process  should  examine 
other  environment  requirements  efforts  to  pro¬ 
vide  input  into  PCIS  requirements  definition 
and  the  PCIS  introduction  process 

Examples: 

Euro-fighter  detailed  requirements, 

MOD  Study  Input 
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PCIS  should  exploit  established  and  emerging  stan¬ 
dards  (de  facto  and  de  jure);  it  should  employ 
such  standards  wherever  possible,  rather  than 
defining  its  own  new  solutions 


The  PCIS  programme  should  address  the  means 
whereby  the  desirability  of  environment  im¬ 
provement  can  be  demonstrated  to  strategic 
decision  makers 


PCIS  products  must  be  designed  for  incremental 
adoption  as  part  of  evolutionary  environment 
improvement;  it  should  be  possible  to  adopt  a 
selected  sub-set  of  the  products 
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The  PC  IS  programme  should  explicitly  address  the 
problem  of  reluctance  to  change,  and  take 
steps  to  increase  the  likelihood  of  actual  use 


The  PGIS  programme  should  provide  a  ‘road  map’ 
to  assist  users  in  exploitation  of  Its  results;  this 
should  cover  (among  other  things) 

-  identification, 

-  justification, 

-  initiation,  and 

-  management  of  environment  improvements 


PCiS  Activities  &  Products 
for  Achieving  Change 


Activities 

Products 

Survey 

Guides/Maps  to  Standards 

Analysis 

Documented  PCIS  benefits 

Evaluation 

Comparison  Guides  for  Standards 

Develop 

PCIS-conforming  vendor  products 

Prototype 

Public  Demos 

Surveys 

Industry  Case  Studies 

Selection 

PCIS-supported  application  domains 

Analysis 

Domain-specific  user  problem  model 

Modeling 

Domain-specific  process  description 

*  Exploit  established  work  including  on-going  PCIS 

work. 

*  An  alternative  set  of  products  should  provide  com¬ 

parable  benefits. 
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PCIS  Laboratories 


"A  potential  PCIS  process  mechanism" 


A  set  of  laboratories  modeled  on  CFI/CFL 

-  Commercially  viable  standards  developed  by 

vendors 

-  Vendors  build  (Integrate)  laboratory  proto¬ 

types  and  demos 

-  User  industry  members  identify  target  prob¬ 

lems 


An  umbrella  organization  to  coordinate  PCIS  labo¬ 
ratories 

-  Provide  strategic  planning 

-  Establish  domain-specific  labs 
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The  PCIS  shall  cover  a  systems  engineering  ap¬ 
proach,  including  software,  hardware  and  man¬ 
ufacturing. 

The  PCIS  should  support  horizontal  tools  and  hori¬ 
zontal  services  (eg.  integration  services  and  re¬ 
lated  stds.) 

User  Interface  Management 
Configuration  Management 
Presentation,  data  and  control  integration 

"If  a  choice  must  be  made,  PCIS  should  focus  on 
horizontal  rather  than  PTI  level  services." 


PCIS  should  allow  tools  to  exploit  emerging  and  ex¬ 
isting  standards.  PCIS  should  not  be  limited  by 
a  specific  set  of  standards,  but  rather  support 
environments  of  tools  that  use  appropriate 
standards. 
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PCIS  shall  provide  a  full  range  of  administrative  ser 
vices,  such  as  those  typically  associated  with 
the  sUperi’User  or  system  manager.  This 
should  inciude: 

user  and  group  creation,  deletion  and 
mgrnt; 

resource  and  device  creation,  deletion, 
and  mgrnt; 

access  control  mgrnt; 

'  •  '  ■  ■  S  ' 

environment  Instance  creation,  deletion 
and  repair. 

PCIS  shall  not  preclude  that  the  development  envi¬ 
ronment  may  also  be  the  target  environment. 
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Traceability  and  Fine-Grained  Data:  PCIS  should 
provide  for  efficient  representation  and  manip¬ 
ulation  of  fine-grained  data  and  f^  traceability 
(connectivity)  amorig  fine  grained  items. 

Examples: 

hypertext 

source  statements  being  traceable  to  re¬ 
quirements 


Federation:  PCIS  should  support  co-operation  and 
integrity  maintenance  among  multiple  hetero¬ 
geneous  data  repositories.  For  example,  tools 
may  have  their  own  data  repositories  that  could 
co-operate  through  federation. 
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Conclusions 

1 .  Mindset  must  change  to  adopt  an  approach  to 
PCIS  that  is  user  needs-pull  oriented  rather 
than  technology-push. 

2.  Focus  on  change  management,  including  clear 
demonstration  of  benefits 

3.  Build  on  established  standards  wherever  pos¬ 
sible,  rather  than  defining  new  ones. 

4.  Provide  for  incremental  and  evolutionary  adop¬ 
tion  and  use,  not  big  bang. 

5.  Currently,  users  need  a  federation  of  heteroge¬ 
neous  repositories.  Allow  for,  but  don’t  require, 
a  single  homogeneous  repository. 

6.  Although  tool  portability  remains  a  requirement, 
interoperability  and  incremental  adoption 
should  be  the  primary  focus. 

7.  Promote  open  integrated  systems  by  providing 
for  facilities,  such  as  fine-grained  and  traceable 
information. 
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Report  of  The  Environment  Users  Session 

Dn  Timothy  Lindquist 

0.  Introduction. 

The  Environment  Users  Working  Group  consisted  of  23  participants  representing  a  broad 
spectrum  of  commercial,  military  and  academic  interests.  The  group  also  included  both  European 
and  US  concerns.  The  working  group  met  the  entire  day  on  Wednesday  of  the  workshop,  and 
for  six  hpufs  on  Thursday.  The  results  of  the  working  group  were  summarized  in  a  plenary 
sessitm  of  the  PCIS  meedng.  The  overheads  for  that  presentation  are  included  in  the  workshop 
report  (as  amended  to  reflect  further  working  group  discussions.)  The  report  also  includes  those 
overheads  of  the  individual  presentations  Ifrom  the  session. 

The  Users  Working  Group  report  contains  the  following  sections: 

0.  Introduction 

1.  Description  of  the  Sessions, 

2.  Individual  Presentations, 

3.  Summarization  of  Discussions, 

4.  Requirements: 

Requirements  on  the  PCIS  Process, 

Requirements  on  the  PQS  Product, 

5.  Conclusions, 

6.  Participants, 

7.  Overiieads  of  Individual  Presentations. 


1.  Desorlption  of  the  Sencons. 

The  Wednesday  session  of  the  Users  Gmup  began  with  introductions,  and  a  presentation 
by  the  chair  on  the  scope  and  objectives  of  the  wtvldng  group.  The  group  was  to  examine  ISPE 
requirements  fttnn  thepospective  of  the  Application  Developer.  Output  from  the  workshop  is 
to  aid  in  tlK  requimnents  validation  activiQr  of  the  PQS  program.  The  working  group  resolved 
tiiat  there  are  many  classes  of  users  that  fall  in  the  categmy  of  application  developers. 
Organizations  that  develop  applications  represent  one  form  of  UKr.  Individual  users  represent 
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another.  Each  has  their  own  set  of  needs  that  may  in  many  instances  conflict.  An  onhogonai 
view  can  also  be  taken,  in  which  users  can  be  seen  to  range  from  manufacturers  to  IPSE  tool 
vendors.  Each  of  these  may  have  separate  distinct  needs. 

Vic  Stenning  reviewed  the  results  of  the  Environment  Users  Session  from  the  London 
meeting,  using  the  overheads  from  the  Users  Working  Group  report  fo>m  that  meeting.  (These 
are  included  in  the  London  Workshop  report.)  The  presentation  included  user  input  to  the  PCIS 
process,  as  discussed  at  the  London  meeting. 

The  floor  of  the  working  group  was  then  opened  for  individual  presentations  relating  to 
user  requirements.  These  presentations  are  described  in  the  next  section  of  this  report. 

As  a  result  of  the  presentations  and  general  discussions,  the  group  had  collected  roughly 
20  requirements.  These  were  divided  into  four  areas: 

o  Technical  requirements, 

o  Identification  and  JustiHcation  of  benefit. 


o  Managing  Change,  and 


o  PCIS  scope. 


Participants  divided  into  four  groups  to  work  on  specific  requirements.  Roughly  one  half 
a  day  was  spent  in  the  break>out  groups,  ftn*  the  purpose  of  formulating  statements  of  the 
requirements  and  their  rationale. 


The  group  reconvened  Thursday  evening  to  review  the  results  of  the  break-outs.  Tim 
Lindquist  presented  the  results  of  the  working  group  in  Friday  morning’s  plenary  session. 


2.  Individual  Presentations. 

Participants  were  invited  to  present  their  list  of  potential  requirements.  Five  presentations 
were  giving  covering  various  aspects  of  PQS  development  and  PCIS  products. 

Vic  Stenning;  Process  driven  requirements,  evolution  and  lego  interfaces. 

A  potential  role  for  PQS  is  to  facilitate  environment  improvement  via  process  diiven 
evolution.  PCIS  should  adopt  a  business  strategy  in  developing  PCIS  that  builds  on 
existing  standards.  The  most  important  PCIS  products  would  provide  a  LEGO  interface 
promoting  of  existing  standards  and  promoting  open  integrated  environments.  PCIS 
should  not  be  another  PTI. 
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John  Leary:  Role-based  requirements  analysis. 

Developing  requirements  representative  of  environment  users  should  be  done  using  a 
role-based  process.  Identify  a  list  of  users  roles,  map  a  workflow  among  roles  and 
identify  problems  from  the  roles  a  workflow. 

Judy  Kemer:  Needs  for  PCIS  Administrative  Services. 

PCIS  should  provide  administrative  services  I'or  managing  users,  groups,  and  other 
super-user  functions. 

Claude  Baudoin:  The  Requirements  process;  technology  push/user-pull. 

SEMATECH  has  taken  a  process,  roles  and  activities  approach  to  identifying  user  needs. 
These  include  busLiess  management,  informadon  management,  operations,  process 
management,  software  development,  application  creation  and  process  development. 

Robert  Rankin  (for  Morron)  Stability,  Systems  Engineering  and  Benefits. 

In  the  personal  view  of  MW  Morron,  users  currently  need  stability  of  the  PCTE  interfaces 
and  attention  to  a  systems  engineering  approach  (as  opposed  to  a  more  restricted  software; 
engineering  only  approach). 

Audrey  Canning:  Identifying  Methods  and  Tools. 

The  MOD  environment  study  identified  many  needs  that  should  be  examined  by  PCIS. 
The  process  used  to  identify  the  needs  would  apply  as  well. 


3.  Summarization  of  Discussions. 

A  majority  of  the  users  discussions  focused  on  the  needs  of  the  PCIS  process  itself.  Tlie 
group  addressed  the  question,  what  should  be  done  to  carry  out  the  PCIS  program  so  that  it 
provides  maximum  benefits  to  its  users? 

The  group  felt  that  the  most  important  issues  for  the  program  lie  in  identifying  problems 
PCIS  can  profitaMy  address,  justifying  the  solution  approach,  and  introducing  change  to  the  users. 
To  provide  more  concrete  input  to  PCIS,  the  group  formulated  a  list  of  activities  and  products 
that  would  carry  out  this  business  approach  to  PCIS.  The  suggestion  is  just  that,  a  suggestion. 
The  group  felt  that  any  equivalent  appitiach  deemed  appropriate  would  be  suffice.  The  working 
groups  particular  approach  is  centered  on  the  PCIS  laboratory  concept  in  which  venders  arc 
in&oduced  early  in  the  development  cycle.  Doing  so  provides  for  early  analysis  and  a  head  start 
in  arriving  at  production  quality  implementations. 
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Business  Drivers 


The  program  will  be  successful  only  if  it  stimulates  considerable  investment  (and  therefore 
buy-in)  from  its  vendor  and  user  communities.  Vendors  will  buy-in  and  users  will  adopt  a 
product,  only  if  they  see  the  potential  benefit  to  their  respective  organizations.  Users  are  aiming 
for  quality,  productivity  and  cost  improvements.  These  must  be  present  within  the  constraints 
of  acceptable  risk,  and  must  take  into  account  the  natural  tendency  to  resist  change.  Quality 
environment  improvements  are  achieved  via  improvements  to  the  process.  The  environment  and 
the  process  by  which  the  environment  is  used  are  closely  related.  The  PCIS  program  must  view 
itself  as  introducing  change  from  this  perspective.  PCIS  must  pay  attention  to  the  hurdles  that 
must  be  overcome  to  introduce  change. 

Feeling  that  PCIS  should  be  user  need  driven  as  opposed  to  technology  pushed, 
formulated  a  set  of  requirements  for  the  PCIS  products.  These  represent  the  needs  of  application 
developers,  both  as  individual  users  and  as  organizational  users.  In  this  area,  focal  themes 
seemed  to  emphasize  openness,  integration  services,  traceability  through  levels  of  refinement, 
employing  existing  standards  technology,  and  services  to  support  cooperation  among  tools. 


4.  Requirements. 


4.1  Requirements  on  the  PCIS  Process  (Introducing  Change). 

The  PCIS  program  should  identify  the  spiccific  user  problems  that  it  aims  to  address,  and  should 
show  how  its  products  can  be  deployed  by  users  to  overcome  those  problems. 

The  PCIS  program  must  involve  continual  user  participation,  and  must  respond  to  user  feedback. 

The  PCIS  requirements  process  should  examine  other  environment  needs  identification  efforts 
to  provide  further  input  into  PCIS  requirements  definition  and  the  PCIS  introduction  process. 

Examples: 


Euro-fighter  detailed  requirements, 
MOD  Study  Input 


PCIS  should  exploit  established  and  emerging  standards  (de  facto  and  de  jour);  it  should  employ 
such  standards  wherever  possible,  rather  than  defining  its  own  new  solutions. 

The  PCIS  program  should  address  the  means  whereby  the  desirability  of  environment 
improvement  can  be  demonstrated  to  strategic  decision  makers. 
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PCIS  products  must  be  designed  for  incremental  adoption  as  pan  of  evolutionary  environment 
improvement.  It  should  be  possible  to  adopt  a  selected  sub-set  of  the  products. 

The  PCIS  program  should  explicitly  address  the  problem  of  reluctance  to  change,  and  take  steps 
to  increase  the  likelihood  of  actual  use. 

The  PCIS  program  should  provide  a  ’road  map’  to  assist  users  in  exploitation  of  its  results;  this 
should  cover  (among  other  things) 

•  identification, 

•  justification, 

•  initiation,  and 

•  management  of  environment  improvements 

Sample  PCIS  Activities  &  Products  for  Achieving  Change 

This  section  presents  more  detail  on  one  manner  that  the  PCIS  process  can  respond  to 
these  requirements.  The  approach  is  based  on  the  notion  of  PCIS  laboratories  and  it  identifies 
specific  activities  (products)  that  should  be  carried  out  (developed.) 


Activities 

Products 

Survey 

Guides/Maps  to  Standards 

Analysis 

Documented  PCIS  benefits 

Evaluation 

Comparison  Guides  for  Standards 

Develop 

PQS-conforming  vendor  products 

Prototype 

Public  Demos 

Surveys 

Industry  Case  Studies 

Selection 

PCIS-suppOTted  application  domains 

Aialysis 

Domain-specific  user  problem  model 

Modeling 

Domain-specific  process  description 
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Guides  and  maps  to  standards  are  needed  to  help  us<sr  organizations  plan  for  future 
investments  and  introduction  of  PCIS-compliant  environments.  The  comparison  guide  for 
emerging  standards  is  for  both  vendor  and  user  planning  It  encourages  standards  convergence. 
The  case  studies,  vendor  public  demonstrations  ano  domain  speciflc  activity  encourage  adoption 
and  investment. 

The  domain-specific  process  descriptions  form  the  basis  fur  project  management  and 
organiiLational  process  improvement  Public  models  are  needed  in  this  area  to  encourage 
introduction  and  process  improvement 

The  example  put  forward  here  is  to  organize  a  set  of  laboratories,  modeled  on  CFI/CFL, 
along  with  an  umbrella  organization  to  oversee  their  coordination.  It  is  assumed  that  the  PCIS 
programme  will  produce  a  set  of  results,  which  specifically  address  user  requirements  and  which 
exploit  existing  products  and  standards.  The  role  of  the  laboratories  in  this  process  are  outlined 
below. 


PCiS  Laboratories:  A  potential  PCIS  process  mechanism 
A  set  of  laboratories  modeled  on  CFI/CFL 

•  Commercially  viable  standards 

•  Vendors  build  (integrate)  laboratory  prototypes  and  demos 

•  User  industry  members  identify  target  problems 
An  umbrella  organization  to  coordinate  PCIS  laboratories 

•  Provide  strategic  planning 

•  Establish  domain-specific  labs 


4.2.  Requirements  on  the  PCIS  Products. 

The  PCIS  shall  cover  a  systems  engineering  approach,  including  software,  hardware  and 
manufacturing. 

The  PCIS  should  support  horizontal  tools  and  horizontal  services  (e.g.  integration  services  and 
related  standards.) 
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0  User  Interface  Management 


o  Configuration  Management 

o  Presentation,  data  and  control  integration 

If  a  choice  must  be  made,  PCIS  should  focus  on  horizontal  rather  than  Pll  level  services. 

PCIS  should  allow  tools  to  exploit  emerging  and  existing  standards, 

PCIS  should  not  be  limited  by  a  specific  set  of  standards,  but  rather  support  environments  of 
tools  that  use  appropriate  standards. 

PCIS  shall  provide  full  range  of  administrative  services,  such  as  those  typically  associated  with 
the  super-user  or  system  manager.  Tuis  should  include: 

•  user  and  group  creation,  deletion  and  management; 

•  resource  and  device  creation,  deletion,  and  management; 

•  access  control  management; 

•  environment  instance  creation,  deletion  and  repair. 

PCIS  shall  not  preclude  that  the  development  environment  may  also  be  the  target  environment. 

Traceability  and  Fine-Grained  Data:  PCIS  should  provide  for  efficient  representadon  and 
inanipuladon  of  fine-grained  data  and  for  traceability  (connectivity)  among  fine  grained  items. 

Examples: 


•  hypertext 

•  source  statements  being  traceable  to  requirements 

Federation:  PCIS  should  support  co-operadon  and  integrity  maintenance  among  muldple 
heterogeneous  data  repositories.  For  example,  tools  may  have  their  own  data  repositories  that 
could  co-operate  through  federadon. 

The  PQS  process  shall  develop  dotiudn  specific  informadon  and  process  models.  Domains  such 
as  DOD  2167A  and  Aerospace  should  be  addressed.  These  shall  be  addressed  in  the  PCIS 
products.  Such  models  are  intended  to  promote  interoperability. 

The  PCIS  shall  develop  and  support  domain  specific  informadon  interchange  formats  and 
protocols.  These  formats  should  support  interoperability  in  heterogeneous  environments. 
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5.  Conclusions. 

5.1.  The  mindset  must  change  to  adopt  an  approach  to  PCIS  that  is  user  needs-pull  oriented 
rather  than  technology-push. 

5.2.  Focus  on  change  management,  including  clear  demonstration  of  benefits. 

5.3.  Build  on  established  standards  wherever  possible,  rather  than  defining  new  ones. 

5.4.  Provide  for  incremental  and  evolutionary  adoption  and  use,  not  big  bang. 

5.5.  Currently,  users  need  a  federation  of  heterogeneous  repositories.  Users  need  cooperation 
among  tools.  Allow  for,  but  don’t  require,  a  single  homogeneous  repository. 

5.6.  Although  tool  portability  remains  a  requirement,  there  are  other  overriding  concerns,  such 
as  interoperability  and  incremental  adoption. 

5.7.  Promote  open  integrated  systems  by  providing  for  facilities,  such  a.s  fine-grained  and 
traceable  information. 
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PCIS  REQUIREMENTS  VALIDATION 
SECOND  WORKSHOP  REPORT 
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Attendees 
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Includes  many  Platform  Suppliers 

-  Even  before  that  group  disbanded. 

-  Platform  Suppliers  are  Environment  Suppliers. 
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XXX  XXX 


Background  Discussions 
Discussion:  Object-Orientation  as  major  WS  1  issue. 

-  Need  to  refine  WSl  consensus  to  integrate  00  and  £R. 

-  00  is  an  "emerged"  technology. 

-  ER  model  is  a  complementary  and  proven  approach 
in  existing  SEE  data  models. 


Presentation:  Chris  Nolan,  ATIS/PCTE  merger  experiment. 

-  PCTE  metaschema  extended  with  function 
attachment. 

-  Some  OO  interfaces  and  PCTE  interfaces  specified. 

-  Prospects  for  such  a  merger  are  encouraging. 


Discussion:  Partitioning  as  major  WS  1  issue. 

-  Modularity  of  interface  sets,  incremental  exploitation 
and  future  incremental  extensibility. 


Discussion:  Interface  Set  Goals  -  Portability  and  Integration. 

-  Implies  completeness,  but  not  all  interfaces  for 
applications  in  general,  and  not  monolithic  interface  set. 
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Requirements  for  Ot^ect  Orientation 

*  Sublstantial  discussion,  and  \  several  trial  proposals. 

-  Goal:  Rejfine  WSl  "4.8  Object  Orientation"  initial 
resolutions. 

>  Goal:  Incorporate  proven  £R  model  concepts  and 
basic  object-oriented  concepts  seen  as  essential  to  tool 
integration  and  extensibility. 

Requirement  4.8  la)  PCIS  shall  support  mechanisms 
for  the  definition  of  abstract  data  types  with  operations. 

Vote:  for:  12,  against:  1,  abstentions:  1 

WSl  Requirement  4.8  lb)  PCIS  shall  support 
extensions  of  abstract  data  types  with  operations  by 
subtyping  (inheriting  attribute  types,  relationship  types, 
and  operations). 

Vote:  for:  12,  against:  1,  abstentions:  1 

Rationale: 

-  "Should"  to  "shall"  to  give  more  force. 

-  The  phrase  "plus  methods"  redundant  with  "abstract 
data  type",  included  for  clarity. 

-  "Inheriting..."  emphasizes  the  intent  of  subtyping. 

-  The  dissenting  voter:  the  requirements  did  not  go  far 
enough;  a  detailed  object-oriented  model  should  be 
required. 

-  The  abstaining  voter:  the  requirements  may  already 
be  too  detailed. 
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Requirements  for  Object  Orientation,,  continued 

WSl  Requirement  4.8  Ic,  Id  and  2a  through  2f  should 
be  deleted. 

Vote:  for  12,  against:  0,  abstentions:  0 
Rationale: 

-  Unnecessarily  specific  requirements  impinging  on 
PCIS  definition  and  on  PCIS  implementations. 

-  Little  support  for  these  requirements  in  the  first 
workshop. 


NRAC  page  37  item  (h). 

Could  be  interpreted  as  incompatible  with  an  object- 
oriented  approach: 

h)  the  NSIS  shall  separate  the  descriptions  of  data  and 
instances  of  data  from  the  tools  that  operate  upon  them. 

Reword: 

h)  The  PCIS  shall  separate  the  descriptions  of  data 
(including  operations  defined  on  the  data)  and  the  instances 
of  data  from  the  tools  that  manipulate  them. 

Vote:  for:  6,  against:  0,  abstentions:  0 

Rationale: 

-  Clarifies  the  intent  that  descriptions  should  reside  in 
the  model. 

-  Not  in  conflict  with  OO. 
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Use  of  "Ada"  In  the  NRAC: 

-  PGIS  definition  should  avoid  language  dependencies 
(except  in  bindings). 

-  Some  occurrences  of  "Ada"  in  the  NRAC  need  to  be 
gendralized. 

Item  (i)  on  page  37  of  the  NRAC: 

i)  The  NSIS  shall  support  Ada  program  libraries. 

Rephrase  as  in  EURAC  to  clarify  that  the  intent  is  to 
provide  a  concrete  example  of  one  application  domain: 

i)  The  data  facilities  shall  be  sufficient  to  support,  at 
least,  Ada  program  libraries. 

Vote:  for:  6,  against:  0,  abstentions:  1 

Alternative:  move  the  requirement  into  the  rationale: 

Vote:  for:  4,  against;  1,  abstentions  2 

Rationale: 

For  -  Requirements  are  already  sufficiently  strong  to 
address  the  application  to  Ada  program  libraries. 

Against  -  Stating  applications  is  an  appropriate 
approach  to  requirements  speciHcation. 
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Use  of  "Ada"  in  the  NRAC,  continued: 

The  editors  of  the  IRAC  should: 

1)  Analyze  occurrences  of  "Ada".  Retain  language- 
specific  references  only  when  there  is  an  underlying 
language  issue.  Refer  to  the  EURAC  in  this  process  (since  it 
has  undergone  this  process).  (Sections  2.SF  and  2.11A  are 
examples  where  references  to  Ada  can  simply  be  removed.) 

2)  Group  together  all  language-specific  requirements 
which  arc  retained.  (For  example  sections  2.14  contains 
such  requirements.) 

3)  Investigate  whether  there  are  C-specific 
requirements  which  should  be  added. 

Vote:  for:  7,  against:  0,  abstentions:  0 

Rationale: 

-  The  PCIS  abstract  specification  (and  hence  its 
requirements)  should  be  language  independent,  where 
possible. 

-  Yet  language  capabilities  should  not  be  compromised. 
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Input/Output  Requirements 

Another  occurrence  of  "Ada": 

4.4E  Ada  Input  and  Output.  The  NSIS  shall  provide  that 
the  input  and  output  facilities  of  the  Ada  language  (as 
defined  in  Chapter  14  of  ANSI/MIL-STD1815A)  can  be  used 
in  reading  and  writing  attributes  whose  values  correspond 
to  Ada  external  file.  The  facilities  of  Section  6  shall  then 
apply. 

Rephrase  as  language-  independent  generalization: 

4.4E  Binding  language  features  applying  to  file 
contents  shall  apply  to  entities  having  file  contents. 

Vote:  for:  11  against:  2,  abstentions:  0 

Rationale: 

-  Vote  addressed  the  statement  of  the  generalization  of 
the  requirement,  not  desirability  of  the  requirement  itself. 

Discussion  opened  the  larger  question  of  whether  the  PCIS 
should  provide  10  interfaces. 

-  If  so,  how  should  these  be  related  to  language- 
defined  10  interfaces  or  run-time  interfaces. 


Input/Output  Requirements,  continued 

Alternative: 

1)  PCIS  shall  provide  basic  10  operations  on  bulk  data 
attributes  (i.e.  contents). 

2)  PCIS  shall  define  the  effect  on  the  object  base  of 
standard  10  facilities  of  a  given  language. 

3)  It  is  desirable  that  compilers  support  PCIS  semantics 
in  implementations  of  the  standard  language  10  facilities. 

Vote:  for:  5,  against:  0,  abstentions:  0 

Rationale: 

-  Requirement  (3)  is  viewed  as  a  design  requirement 
for  PCIS.  That  is  PCIS  should  facilitate  the  implementation  of 
such  10  facilities. 

-  Language-independent  standard  10  facilities  aid 
portability  and  provide  a  basis  for  the  implementation  of 
language-dependent  10  facilities  which  interface  with  the 
PCIS  object  model. 

-  Permits  e.g.  security  requirements  and  object  base 
effects  for  file  access. 

-  Requirement  (2)i  compiling  systems  may  be 
consistent  in  what  effects  10  facilities  have  on  the  object 
base.:;.  ,  \ 


*  Requirement  (1):  offers  the  possibility  of  consistency 
of  content  structures  across  compiling  systems. 
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2.6  Partitioning 

Replacement  2.6  (NRAC  &  WSl)  with  refinements: 

1)  PCIS  shall  be  partitioned. 

2)  Each  partition  consists  of  a  set  of  services  and  an 
interface  set,  where  the  services  and  interface  set  are  self- 
consistent. 

3)  Any  given  service  may  be  a  component  of  one  and 
only  one  partition. 

4)  PCIS  shall  specify  the  interdependence  of  any  pair 
of  partitions. 

5)  PCIS  shall  define  levels  of  conformance  for 
implementations  in  terms  of  the  provision  of  specific 
partitions. 

Vote:  for:  5,  against:  0  abstentions:  0 

Rationale: 

-  The  desirability  of  partitioning  is  emphasized. 

-  Incremental  exploitation  (implementation,  use  by 
tools,  installation)  is  facilitated. 

-  Modularity  is  enhanced. 

-  Services  and  interfaces  are  distinguished.  In  the 
object-oriented  module,  a  single  set  of  interfaces  may 
provide  access  to  many  services. 

"  Redundancy  of  functionality  is  undesirable  —  e.g. 
confusing  and  wasteful. 
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SECOND  WORKSHOP  REPORT 
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Attendees 
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6/05/91  PM 

6/06/91  PM 

G.  Clow  (SofTech) 

X 

X 

X 

R.  Minot  (GIE  Emeraude) 

X 

X 

X 

C.  Hitchon  (SofTech) 

X 

X 

X 

Y.  AU  (BNR) 

X 

E.  Black  (Atherton) 

X 

X 

X 

G.  Boudier  (GIE  Emeraude) 

X 

X 

X 

C.  Bremeau  (GEE  Emeraude) 

X 

X 

X 

K.  Bruso  (Unisys) 

X 

X 

J.  Dawes  GCL) 

X 

R.  Ekman  (IBM) 

X 

X 

K.  Hayter  (DRA) 

X 

M.  Horton  (Unisys) 

X 

X 

X 

M.  Kavianpour  (IBM) 

X 

C.  Nolan  (DEC) 

X 

X 

X 

H.  OUver  (HP) 

X 

X 

G.  Memmi  (BuU  Hn) 

X 

X 

X 

J.  Prints 

X 

X 

W.  D.  Song 

X 

X 

Introduction; 

The  Platform  Suppliers  Group  was  small  disbanded,  in  part  becaos  pjadorm 
were  intetested  in  the  environment  supple  grcHip.  Members  of  the  disbtmd^  proupna^red 
to  tire  Enviimunent  Supplim  Group.  It  vm  observed  that  pUtfmm  supplietrsne  ^neni]ly«^ 
environment  suppliers. 
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Presentations: 


Chris  Nolan  gave  a  presentation  on  an  experimental  AUS/PCTE  merger  in  which  PCTE 
provided  the  underlying  data  model  management  services.  The  prospects  for  the  success  of  such 
a  merger  were  found  to  be  encouraging. 


Discussion:  Object-Orientation. 

The  first  workshop  identified  an  object-oriented  capability  as  a  requirement.  However, 
the  ER  model  is  a  complementary  and  proven  approach  in  existing  SEE  data  models. 


Discussion:  Partitioning. 

The  first  workshop  identified  partitioning  of  the  interface  set  as  a  useful  approach  for 
modularity  of  interface  sets,  incremental  implementation  and  future  incremental  extensibility. 


Discussion:  Interface  Set  Goals  •  Portability  and  Integration. 

Portability  implies  completeness  in  the  sense  that  all  important  services  for  tools  must  be 
provided.  It  was  observed  that  such  a  requirement  is  far  more  Umited  than  providing  all 
interfaces  for  applications  in  general. 

Tool  integration  requires  the  selection  of  existing  standards  already  in  use  or  planned  for 
use.  PQS  should  avoid  the  implementation  of  that  which  is  already  available.  Extensibility  is 
requited  to  support  tool  composition. 


Requirements  for  Object  Orientation: 


Several  general  requirements  were  proposed  concerning  PCIS  support  for  an  object- 
oriented  data  model. 

General  Object-Oriented  Requirement  Alternatives; 

1.  PCIS  shall  have  an  object  model. 

Vote:  None. 

Radonale: 

Such  a  requirement  was  seen  as  too  vague,  particularly  the  use  of  "object 
model". 

2.  PCIS  shall  be  expressed  through  its  object  model. 

Vote:  None. 

Radonale: 

Again,  "object  model"  is  vague  and  could  be  seen  as  constraining  the 
standard  to  an  "object  oriented"  descripdon. 

3.  PCIS  shall  provide  a  data  model  which  supports  modeling  of  objects  with  types, 
type  inheritance,  attribute  types,  reladonship  types  and  operadons  applicable  to 
instances  of  those  types. 

Vote;  for  14,  against,  0:  abstendons:  0 

Radonale: 

-  The  requirement  inctxporates  the  proven  ER  model  concepts  of  exisdng 
standard  as  well  as  basic  object-oriented  concepts  seen  as  essendal  to  tool 
integradon  and  extensibility. 

-  Aldiough  thtat  was  stmie  disagreement  with  imposing  a  particular  data 
model,  it  was  also  nmed  that  some  data  model  must  be  observed  in  the 
IRAC  in  onter  to  adequately  express  the  requirement.  Hfowever,  this  does 
nm  require  a  particular  data  m^l  for  the  PQS. 
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Object-Oriented  Issuer: 


The  following  were  points  of  discussion.  The  issues  are  already  addressed  by  NRAC  and 
no  motions  for  revision  arose. 

Should  inheritance  be  required  on  types  other  than  object  types  (i.c.,  relationship 
types  and  attribute  types)?  Are  relationships  "first  class"  objects  in  the  sense  that 
attributes  and  operations  can  be  associated  with  relationship  types? 

Is  multiple  inheritance  required? 

Are  multiple  implementations  of  methods  permitted  (as  in  abstract  data  types)? 


4.8  Object  Orientation 

The  alternative  detailed  requirenwnts  formulated  in  the  first  PCIS  workshop  were 
discussed.  The  first  two  requirements  in  alternative  1  were  rephrased  and  then  voted  upon: 

la.  PCIS  shall  support  mechanisms  for  the  definition  of  abstract  data  types  with 
operations. 

Vote:  for:  12,  against:  1,  abstentions:  1 

lb.  PCIS  shall  support  extensions  of  abstract  data  types  with  operations  by  subtyping 
(inheriting  attribute  types,  relationship  types,  and  operations). 

Vote:  for:  12,  against:  1,  abstentions:  1 

Rationale: 

Rephrasing  changed  "should"  to  "shall”  to  give  more  force  to  the  requirement. 

The  phrase  "plus  methods"  was  replaced  by  "with  operations",  expressing 
essentially  the  same  requiimnent  witiitmt  the  implicatictn  of  a  commitimnt  to  a 
strictly  object-<nmnted  model.  Although  bodi  phrases  are;  redundant  with  "abstract 
data  type",  the  later  phrase  was  included  for  clarity. 

The  phrase  "Alntract  Data  Types"  was  changed  to  lower  cam  to  indicate  that  tlw 
gen^  concqit  of  atatract  data  types  is  referenced. 

•  The  phrase  "inheriting  attribute  types,  rehttimiship  types  ami  qjenuUms"  was 
adUed  to  (lb)  to  emphasize  the  intent  of  subbing. 


The  dissenting  voter  felt  that  the  requirement  did  not  go  far  enough;  that  they  do 
not  really  say  what  the  data  model  must  be,  and  that  a  detailed  object-oriented 
model  should  be  required. 

The  absenting  voter  felt  that  the  requirement  may  already  be  too  detailed. 


The  requirements  Ic,  Id  and  2a  through  2f  were  considered  and  their  deletion  was  voted 
upon  as  a  group: 

Vote:  for  12,  against:  0,  abstentions:  0 
Rationale: 

These  requirements  were  generally  seen  as  unnecessarily  specific  and  tending  to 
require  object-oriented  implementation  techniques. 

There  was  relatively  little  support  for  these  requirements  in  the  first  workshop. 


NRAC  page  3' '  item  (h). 

It  was  pointed  out  that  the  following  requirement  in  the  NRAC  could  be  interpreted  as 
incompatible  with  an  object-oriented  approfu;h: 

h)  the  NSIS  shall  separate  the  descriptions  of  data  and  instances  of  data  from  the 
tools  that  operate  upon  them. 

The  following  rewarding  was  suggested: 

h)  The  PCIS  shall  separate  the  descriptions  of  data  (including  operations  on  the  data) 
and  the  instances  of  data  firom  the  tools  that  manipulate  them. 

Vote:  far.  6,  against:  0,  abstentitxis:  0 


RatitMiale: 

The  lewonUng  clarifiM  the  intent  that  die  descriptitms  of  daa  and  qperations 
shmiU  leikle  hi  the  model  and  not  be  embedded  within  tte  tools  which  use  mottel. 
Tte  rewofding  is  ikm  in  conflict  with  an  tdiject-oriented  model. 
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Use  of  "Ada"  in  the  NRAC: 

It  was  observed  that  a  goal  of  the  IRAC  and  the  PCIS  definition  is  to  avoid  language 
dependencies  (except  in  the  language  bindings)  and  that,  some  occurrences  of  "Ada"  in  the  NRAC 
may  need  to  be  generalized. 

Item  fi)  on  page  37  of  the  NRAC  is: 

i)  Tliic  NSIS  shall  support  Ada  program  libraries. 

A  rephrasing  of  this  statement  in  the  EURAC  was  proposed  to  clarify  that  the  intent  is 
that  the  database  facilities  should  be  sufficient  to  support  the  implementation  of  Ada  program 
libraries: 


i)  'fhe  data  facilities  shall  be  sufficient  to  support,  at  least,  Ada  program 
'libraries. 

Vote:  for:  6,  against:  0,  abstentions:  1 

Rationale: 

Specific  mention  of  languages  should  be  confined  to  areas  where  language  binding 
is  discussed.  However,  in  this  case  no  language  dependency  is  described.  The 
irequirement  merely  uses  the  implementation  of  Ada  program  libraries  as  an 
example  of  capabilities  that  must  be  provided  through  the  PCIS. 

An  alternative  proposal  was  to  move  the  requirement  into  the  rationale. 

Vote:  for:  4,  against:  1,  abstentions:  2 

Rationale: 

For:  The  requirement  itself  is  real.  That  is,  the  data  model  requirements 

are  already  sufficiently  strong  to  address  the  application  to  Ada  program 
libraries.  This  application  could  simply  be  mentioned  in  the  rationale  for 
data  motteling  requirements. 

Against:  Stating  concrete  requirements  with  examples  is  an  appropriate 

qyproach  to  requirements  specification. 

Further  discussion  of  the  issue  of  the  use  of  "Ada"  in  the  NRAC  lead  to  the  following 
recamnendatiems  tt>  tte  e^tens  of  the  IRAC: 
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1.  Analyze  occurrences  of  "Ada".  Retain  language-specific  references  only  when 
there  is  an  underlying  language  issue.  Refer  to  the  EURAC  in  this  process  (since 
it  has  undergone  this  process).  (Sections  2.SF  and  2.11  A  are  examples  where 
references  to  Ada  can  simply  be  removed.) 

2.  Group  together  all  language-specific  requirements  which  are  retained.  (For 
example,  section  2.14  contains  such  requirements.) 

3.  Investigate  whether  there  are  C-specific  requirements  which  should  be  added. 
Vote:  for:  7,  against:  0,  abstentions:  0 

Rationale: 

These  recommendations  follow  directly  from  the  desire  for  language-independence 
in  the  PCIS  abstract  specification.  They  also  point  out  that  the  investigation  of  potential 
language-dependent  issues  (such  as  implementation  problems)  needs  to  begin  in  the 
formulation  of  requirements  and  continue  through  the  definition  phases. 
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Input/Output  Requirement;:, 

Another  occurrence  of  "Ada"  in  the  NRAC  is  requirement  4.4E  on  page  54: 

4.4E  Ada  Input  and  Output.  The  NSIS  shall  provide  that  the  input  and  output 
facilities  of  the  Ada  language  (as  defined  in  Chapter  14  of  ANSI/MIL- 
STD-1815A)  can  be  used  in  reading  and  writing  attributes  whose  values 
correspond  to  Ada  external  files.  The  facilities  of  Secdon  6  shall  then 
apply. 

An  alternative  phrasing  of  requirement  was  proposed  as  a  language-independent 
generalization  of  NRAC  requirement. 

4.4E  Binding  language  features  applying  to  file  contents  shall  apply  to  entities 
that  have  file  contents. 

Vote:  for:  11,  against:  2,  abstendons:  0 

This  vote  addressed  the  statement  of  the  generalization  of  the  requirement  rather 
than  the  desirability  of  the  requirement  itself. 

The  rephrasing  has  actually  opened  the  larger  question  of  whether  the  PCIS  should 
provide  10  interfaces,  and  if  so,  how  these  should  be  related  to  language-defined  10 
interfaces  or  run-time  interfaces  which  may  be  provided  as  part  of  the  platform  on  which 
the  language  is  used.  During  this  discussion  the  following  lO  related  requirements  were 
formulated  and  voted  upon.  These  requirements  replace  and  refine  4.4E  above: 

1.  PCIS  shall  provide  basic  10  operations  on  bulk  data  attributes  (i.e.,  contents). 

2.  PCIS  shall  define  the  effect  on  the  object  base  of  standard  10  facilities  of  a  given 
language. 

3.  It  is  desirable  that  compilers  support  PCIS  semantics  in  implementations  of  the 
standard  language  10  facilities. 

Vote:  for:  5,  against:  0,  abstentions:  0 

Rationale: 

Requirement  (3)  is  viewed  as  a  design  requirement  for  PCIS.  That  is,  PCIS 
should  facilitate  the  implementation  of  such  lO  facilities. 
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Liinguage-independent  standard  10  facilities  are  an  aid  to  portability.  They  also 
provide  a  basis  for  the  implementation  of  language-dependent  10  facilides  which 
interface  with  the  PCIS  object  model. 

Both  PCTE  and  CAIS  provide  10  interfaces.  A  key  rationale  for  these  interfaces 
is  that  additional  semantics  regarding  the  effects  of  10  operations  on  entities 
having  contents  are  defined  by  both  standards.  Also,  the  management  of  security 
requirements  regarding  file  access  is  necessary.  This  may  present  implementation 
problems  or  require  the  copying  of  files  (e.g.,  export^import)  prior  to  and/or 
following  access. 

Requirement  (2)  assures  that  compiling  systems  will  be  consistent  in  what  effects 
lO  facilities  have  on  the  object  base.  Requirement  (1)  offers  the  possibility  of 
consistency  of  content  structures  across  compiling  systems. 

PCTE  provides  primitive  lO  operations  which  allow  the  implementation  and 
substitution  of  run-time  lO  interfaces  which  are  integrated  with  PCTE  object 
management.  This  solution  is  often  viable  when  the  desired  compiling  system 
support  mentioned  in  (3)  is  not  available. 

It  is  unlikely  that  compiler  suppliers  will  have  much  interest  in  customizing 
language  10  operations  to  interface  with  PCIS.  However,  on  some  platforms  there 
may  be  hooks  into  the  operating  system  for  reporting  10  operations  or  it  may  be 
possible  to  substitute  PCIS  integrated  10  interfaces  for  those  nomially  called  using 
the  linker.  There  is  no  assurance  that  the  necessary  facilities  or  hooks  will  always 
be  available. 
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Partitioning; 


Partitioning  of  the  PCIS  interface  set  was  discussed.  The  general  feeling  was  that 
partitioning  is  desirable.  The  following  requirements  were  proposed  as  replacements  for  those 
in  section  2.6  proposed  in  the  first  workshop  and  those  included  in  the  NRAC. 

1.  PCIS  shall  be  partitioned. 

2.  Each  partition  consists  of  a  set  of  services  and  an  interface  set,  where  the  services 
and  interface  set  are  self-consistent. 

3.  Any  given  service  may  be  a  component  of  one  and  only  one  partition. 

4.  PCIS  shall  specify  the  interdependence  of  any  pair  of  partitions. 

5.  PCIS  shall  define  levels  of  conformance  for  implementations  in  terms  of  the 
provision  of  specific  partitions. 

Vote:  for:  3,  against:  0,  abstentions:  0 

Rationale: 

The  desirability  of  partitioning  is  emphasized.  Although  requirements  for  both 
CAIS-A  and  PCTE  mention  partitioning,  no  true  partitioning  occurs  in  these 
standards.  Problems  with  monolithic  interface  sets  were  acknowledged.  The 
entire  interface  set  should  not  be  forced  upon  applications  which  require  only 
some  small  portion  of  the  services  available. 

Services  and  interfaces  are  distinguished.  In  the  object-oriented  model,  a  single 
set  of  interfaces  may  provide  access  to  many  services. 

Redundancy  of  functionality  is  undesirable.  Redundancy  tends  to  confuse  and 
lead  to  wasteful  multiplicity.  Thus,  multiple  partitions  should  not  provide  the 
same  services. 

The  interdependencies  must  be  specified  by  the  PCIS  in  order  that  the  benefits  of 
partitioning  can  actually  be  exploited  to  minimize  development  costs  and  other 
resource  requirements.  The  ability  to  partition  the  services  must  be  designed  into 
the  specification  of  the  services  and  their  inteirelationships. 

The  services  which  cannot  act  independently  are  naturally  grouped  in  the  same 
partition. 
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Wording  Suggestion: 

It  was  suggested  that  the  IRAC  use  terms  such  as  "valid"  or  "invalid"  in  place  of  "legal" 
and  "illegal". 

Vote:  none. 
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ATIS 


A 

Tools 

Integration 

Standard 


History 


Original  work  done  in  a  CAD  environment 

Atherton  Technology  founded  to  develop 
the  same  ideas  for  CASE 

In  partnership  with  Digital,  concepts 
extended  to: 

-  Eliminate  UNIX  dependencies 

-  Enhance  relationship  support 

-  Modularize  and  generalize  facilities 

-  Add  dictionary  concepts 

CIS  committee  started  to  gather  industry 
ideas 


Goals 


Provide  services  that  can  support  the  entire 
appiication  development  iife  cycie 

Scope  inciudes  traditionai  CASE  repositories 
and  traditional  data  dictionaries 

Address  the  problem  of  gro\A/ing  numbers 
of  disparate  repository  &  dictionary 
standards 


What  is  ATIS  ? 
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Side  No 


structure 


1 .  ATIS  description  broken  out  into  "modei 

2.  Each  modei  describes  a  concept; 

A.  Base  Object  Modei 

B.  Versioning 

C.  Configuration  Management 

D.  Toois  Integration 

E.  Work  Flow  Control 


F.  Dictionary  Extensions 


Base  Object  Model 


Provides: 

•  objects,  properties,  methods 

•  a  v/oy  of  sending  messages 

•  utiiity  functions 

•  a  simple  type  hierarchy 


Refining  Operations 


Allows  for  the  behavior  of  the  system  to  be 
tailored  to  the  site. 

•  Vendor  operations  must  kept  separate 
from  site  customization,  so  updates  to  the 
system  leave  site  changes  intact 


ATIS  preambles  and  postambles  allow 
customizations,  and  keep  them  distinct  from 
vendor  supplied  behavior 


Version  Model 


Introduces  versions  and  variants 

Can  create  variants  of  variants;  can  merge 
variants 

Reserve/Repiace  mechanism  controis 
concurrent  creation  of  new  versions 

Aiiows  versioning  of  types 


Configuration  Model 


•  Introduces  configurations 

•  A  configuration  represents  all  elements  of  a 
particular  version  of  a  system 

•  Configurations  change  \Arhen  their  contents 
change 

•  Configurations  are  changed  via 
reserve/replace 

•  Contexts  represent  views  of  the  repository 

•  Aggregates  represent  elements  external  to 
the  repository 
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Slide  No.  10 


Tool  Integration 


Allows  new  tools  to  extend  the  system 

Allows  tools  to  moke  themselves  known  to 
ATIS 

Mokes  It  possible  for  ATIS  to  Invoke  the  tool's 
Implementation  of  o  method 


Work  Flow  Model 


•  Controls  configurations  as  they  move 
through  the  system  development  and 
approval  process 

•  Documents  and  enforces  policy  on  stages 
of  development 


Slide  No.  12 


ATIS  Object  Model 


0  Element 

1  Named_Element 
2  Branch 
2  Context 
2  IRD-VIEW 
2  Database 
2  NAMES 
2  Partition 
2  Role 
2  User 
2  Version 

3  Aggregate 
4  Binary 

5  Binary  Tool 
5  Text 

6  Text 


Tool 


4  Collection 
3  Message 
3  Tool 

4  Method 

1  Relationship 

2  Depends-on 

3  CONTAINS 
3  MEMBER-OF 
3  USES 


Meta  Schema 


0  Elenveni 
1  Named_Element 
2  Version 
3  Type 

4  Data_Type  ^ 

4  Element  Type 

5  relatTonjype 


4  PROPERTY  TYPE 


CIS 


CASE  Integration  Services 


“The  CIS  committee  will  develop  or  adopt  a 
set  of  standard  interfaces  that  promote  the 
integration  of  software  engineering  tools" 


An  ad  hoc  group  of  interested  CASE 
industry  vendors  and  users 

Started  by  Digital  and  Atherton  to  consider 
ATIS 

Charter  strictly  limits  activities  to  address 
integration  issues 

CIS  assumes  the  presence  of  portability 
services 


Now  it  has  been  proposed  as  an  ANSI 
technical  committee 


other  Standards 


IRDS: 

ATIS  has  been  submitted  to  ANSI  and 
ISO  committees 

CFI: 

ATIS  can  be  applicable  to  CAD 
OMG: 

ATIS  could  be  implemented  using  the 
ORB 


CDIF: 

could  be  used  by  tools  within  an  ATIS 
compliant  environment 

POSIX: 

ATIS  should  be  implementable  on  top 
of  a  POSIX  compliant  system 


ATIS  vs.  PCTE 


ATIS  in  some  areas  is  a 

-  subset  of  PCTE  (SEC  ,EXE,ACT) 

-  superset  in  other  (CMS,  SMS) 

Overiap  in  the  base  type  hierarchy  (e.g.  fiie 
concept)  and  some  common  concepts 
(versioning,  configuration) 

PCTE  does  not  provide  faciiities  to  define 
the  behavior  of  the  object  types 

ATiS  is  iess  descriptive  than  PCTE  in  the 
reiationships  between  types 


>  merge  to  get  the  best  of  both  worlds 


ATIS  on  PCTE 


Offer  an  ATIS  interface,  built  using  the  PCTE 

facilities. 

Pros: 

•  Get  distribution,  security,  concurrency  'for 
free' 

•  Create  a  portable  impiementation  across 
multiple  platforms 

Cons: 

•  Instances  must  be  created  and  accessed 
from  the  same  interface:  PCTE  or  ATIS 

•  Does  not  solve  the  'data  model'  problem: 
one  repository,  two  data  models 


f  > 


v'^y'ri  f  f  oy  * 
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Slide  No.  20 


ATIS  and  PCTE 


•  PACE  =>  PCTE 

ATIS 

Common 

Environment 

•  Merge  the  implementation:  introduce 
messages  and  methods  for  PCTE  types 

•  Merge  the  data  model:  where  scopes  are 
the  same  bring  two  object  types  into  one 


ATIS  and  PCTE 


•  Use  PCTE  links  and  SDSs  to  achieve  different 
views  of  the  common  model 

ATIS  has  a  restricted  view  of  the  PCTE 
object  base 

•  Two  interfaces  and  a  merged  data  model 

==>  access  any  instance  from  both  the 
interfaces 


PACE  Example 


pred§C0ssor/8ucGessor 


Visible  under  PCTE 


Visible  under  ATtS 


Merging 
PCTE  and  ATIS 


PCTE  Services 


ATIS  Services 


Message 

Dispatcher 


Semantic  Layer 
of  PCTE/CIS  methods 


PCTE  and  CIS  primitive  services 


OMS 
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Slide  No.  24 


Versioning 


T 


Configuration 


PCIS  Working  Group 
NoGds  of  PIstforrn  Provid©rs 
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PCIS  -  Needs  of  Platform  Providers 
[15-20  min  Tues,  6/4  ■  4pm] 


Not  new  needs  -  just  amplify  those  in  NRAC  and  1st  workshop 

Software  Development  is  crucial  to  platform  providers  -  software  sells  hardware 

Platform  provider  is  also  tool  provider,  environment  provider  and  environment  user 

Portability  and  Connectivity  to  various  platforms,  not  just  Unix 

Need  to  suppon  various  domains  -  “Business”  software  development  as  well  as  technical 

Support  of  evolving  Hardware  environments  -  e.g..  Distributed  Heterogeneous  Workgroups  i:  .  I 

N^  ability  to  attract  ISV’s  •  pracdcal  and  wide-spread  standards 

Platform  Vendor  -  Interconnecdvity  is  mandatory  (operational) 

-  Interoperability  (portability)  is  desirable  (to  attract  tools) 

Layer  on  top  of  other  standards  -  no  arbitrary  new  standards  [  OSF,  POSIX,  XPG,  ACE  ] 

Ne^  for  (independent)  cerdficadon  of  tools  and  environments  .  ,  ,  ,  .  ^  ^ 

Need  for  Roadmap  -  phased  implementadon  and  delivery  ^  '  .w.U'  -■  v'  i  >  '  - 

-  Customers  can’t  wait  -  want  evoludon  and  migradon  (protect  investment) 
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Needs  of  Tool  Builders 


Attendees 

Jorge  Anderson 
Francois  Audras 
Kurt  Beitz 

Jean  Philippe  Bourguignon 
Bob  Borowski 
Herm  Fischer  (chair) 

Hans  Keus  (co-chair) 

Bob  Munck 
Hirogi  Ochii 
Erhardt  Ploedereder 
Ciyde  Roby 
Bert  Rubenstein 
Nick  Wyboit 
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Activities 


Presentations 

Nick  Wybolt,  Cadre 

General  Work 

Review  of  Recommendations  from  Heathrow  Sessions 
Deveiopment  of  Success  Factors  —  Avoidance  Items 
Identification  of  New  Needs 
Discussion  of  Control  Integration 
Consideration  of  commitment  to  external  standards 
Unfinished  Heathrow  Business 

PCIS  Implementation,  all  of  it  versus  parts  of  it 


Nick’s  Cadre  Presentation 


Herm’s  summary 

Integration  Technology 

Must  be  from  platform  supplier 
Must  be  dependably  present 

Baby  Steps 

Ul  look  and  feel 
Pilot  projects  first 

Data  Integration 

Concerned  about  performance  (vs.  granularity) 

Granularity 

Non-pervasive  repositories 

Tools  give  UIDs  on  private  data  to  public  relationship  managers 
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Heathrow  issues 


T1  What  should  PCIS  Provide 

T6  Configuration  Management 

T7  Tool  communication 

T10  Object  Orientation 

T1 1  Interoperability  and  language  binding 

T12  Networking 

T13  User  Interface 

T1 5  Data  Exchange  between  environments 
T16  Licensing  and  accounting 
T17  Net  based  help 
Tt8  Future  Work 
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Subjective  Evaluation  by  Tool  Vendors 
(or  Environment  Vendors) 


What  should  PCIS  (program,  product)  look  like? 

We’ve  been  talking  to  ourselves  since  1981 
People  are  writing  and  starting  to  use  frameworks 
People  (tool  writers)  are  complaining  about  frameworks 
We  should  evaluate  and  do  pilot  projects  on  PTis/frameworks: 

-  PCTE,  PCTE+.  CAIS 

-  Atherton,  Cohesion,  EAST,  Enterprise  2,  ESF,  SoftBench 

Build  a  matrix  of  likes  and  dislikes 

produces  "assessment^  of  strengths  &  weaknesses 
of  PTIAramework  technologies 

Pick  PTIAramework  technology  and  PCIS  should  define  a 
next  generation  of  /A^Aechnology 
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General  Importance 


Success 


Avoidance 


Corporate  Backing 

Ubiquity 

Availability 

Platform  Support  (framework  bought 
from  hardware  supplier) 

Large  selling  market 
Commercial  acceptance 

Compatibility  with  existing  stan¬ 
dards  at  release  time 

Low  Cost  per  seat 


Incremental  Acquisition 

Performance 

»1  implementation 

with  good  performance 


Unique 

Schema  Control 

Platform  supplier  has  private 
framework  architecture 

Small  market 

DoD  too  small  (may  be  a  stigma) 

Dependence  on  standards 
recently  demised  at  release 

High  cost  per  seat 

Impact  to  computer  operations 
impact  to  project  schedules 

Monolithic  acquisition  &  use 

Workarounds 

only  1  implementation 
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Tool  Supplier  Issues 


Success 


Avoidance 


Reduce  Tool  Cost,  Risk  Customer  needs  PCIS  Installed 

(PC  Excel  situation) 

Integration  Customer  has  to  integrate 

-  Internally  (betw.  supplier’s  tools)  (schema?) 
is  a  must 

-  externally  (betw.  diff.  suppliers) 
is  nice 


Early  availability  prior  to 
host4>latform  release 


PCIS  lags  platform  releases 
Tools  are  late  to  be  ported 
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Modular  Framework 
Non-monolithic  Framework 


Requirement 

PCIS  shall  facilitate,  to  a  maximum  degree,  the  decoupling 
of  functionai  areas  so  that  these  functional  parts  can  be 
used  separately 

Comments 

Group  "minimum  configurations"  -  "levels  of  PCIS  compatibility" 
Avoid  "random"  subsets 

Need  modular  non-monolithic  ("poiyiithic")  framework 
Functional  "parts"  should  have  all  of  their  components 
PCIS  can  be  defined  modularly 

The  PCIS  implementation  can  be  built  modularly  using  separate 
parts 
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Levels  of  Conformance 


Validation  suites 

Tool  works  on  several  Implementations 
Verification  that  tool  is  PCiS  *•  clean 
Work-arounds  are  identified 

Define  compliance  in  parts 

■i—x— 

Performance  evaluation  benchmarks 
Benchmarks  are  part  of  the  PCIS  specification 


Minimal  Capability  to  Integrate 
Multiple  Object  Mgrs. 


Cohabitating  Object  Managers 

Different  Granuarity  Object  Managers  sharing  or 
cooperating 

E.g.,  Ontos-PCIS  installed  on  an  Emeraude*PCIS 
UID  Assignments 

Names  and  Navigation  across  Object  Managers 

Subtyping  and  methods  integration  between  cohabitating 
Object  Managers 

-  lower  granularity  specializes  higher  gran,  methods 

Ability  to  install  low  glevel  readers/Writers  or  handler  for  private  data 
Control  Coordination  at  object  level  and  across  granularity  boundary 
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PCIS  and  External  Standards 


They  change 

Do  they  apply  at  the  right  level 
Do  they  replace  us 

Want  as  few  as  possible 

Define  areas  which  need  standards  identified 
Identify  singie  or  multiple  standards  in  the  area 
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Needs  of  the  Tool  Builders 

Wednesday  A.M. 

Introduction 


Attendance 

Wed.  AM 


Jorge  Anderson  X 

Francois  Audras  X 

K.  Beitz  X 

J.P.  Bouiguignon  X 

Bob  Boroirsfci  X 

H.  Fischer  X 

H.  Kreuz  X 

R.  Munck  X 

Hirogi  Ochii  X 

E.  Ploedereder 

C.  Roby  X 

Bert  Rubenstein  X 

N.  Wybolt  X 


Wed.  PM  Thurs.  PM 
X 
X 
X 

X 

X 

X 


X 

X 


What  the  First  PCIS  Workshop  Tool  Builders'  WG  did 

What  should  we  do  this  time? 

Generate  Additional  requirements  for  IRAC  with  Rationale 
Review  what  we  did  last  time  as  starting  point 

What  is  tlie  IRAC  supposed  to  be  specifying? 

-  should  we  prMuce  PTI,  POM,  PCMfpublic  control  manager)  or 
PPMfpoblic  process  manager)? 

-  last  time,  a  large  focus  was  on  user  requirements 

-  still  don't  have  a  mission  statement 

.  consumen  need  rmntrol  over  their  data  structure  and  contents 
tool  swapability 
consumer  spedfied  processes 
process  persitence 

-  consumen  need  to  tool  -  address  installmion 

-  data  aharabiliQr 

.  control  exchange 

tool  out  of  toaster  model 

more  complicated  process 
depending  upon  which  implementation 

consumer  will  tell  tool  builder  what  their  class  structure  is  like 
different  vendors  have  different  structures 
will  be  populated  in  different  ways 

need  for  powerful  tools  and  procedures  for  those  people  who  do  installation 
of  tools,  because  they  are  swamped 

me  we  confusing  basic  system  administration  with  installation  of  the  tool 
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Activities 

•  Nomintte  New  Tool  Builder  Needs 

2nd  Mtp  Builder  Needs  to  User  Needs 

-  List  Success  Factors 

-  List  Avoidance  Items 

most  tools  should  be  run  out  of  the  box 

problems  occur  with  "pushing  the  envelope"  of  the  tool 

some  problems  occur  with  tailored  installation 

integration  of  tools  within  framework 

toaster  model  marketed  as  frameworks 
Atherton 
HP  Softbench 
DECS  Cohesion 
EAST 

Enterprise  II 
Eureka  SW  Factory 
EuroFighter  IPSE 

size  of  tool  also  makes  a  difference 

e.g.  Verdix  Ada  Compilation  System  needs  almost  one  full  time  person 

bigness  of  tool,  or  pervasiveness  throughout  the  environment? 
implies  higher  level  things  in  the  structure 


small  tool,  e.g.  pretty  printer 

will  inherit  from  higher  levels 
implication  of  some  possible  changes 

even  different  implementations  of  PCTE  have  different  schemas 
tools  developed  for  one  may  not  work  for  others 

IPSEs  have  seen  built  without  frameworks  for  years  through  "glueware” 
wsv  to  model  the  integration  of  tools,  point-to-poiitt 
add  framework 

must  now  hope  that  this  integration  is  still  easily  modified 

users  coming  back  with  additional  requirements 
spcified  data  structur:  and  contents 
want  to  articulate  our  own  process;  not  within  tool 
point-tO‘pQiJtt  could  hide  process 

are  process'  a  user  WANT  or  NEED?  is  this  a  fad? 

AD/Cyde  calls  out  process  modelling 

probably  first  to  do  so  in  commercial  product 
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rure  Commercial  (Not  militaiy,  not  aero) 

not  as  aware  of  process  modelling,  perhaps 
they  are  more  interested/concemed  in  puttnig  forth  best  practices 
more  t/er^ar  to  do  their  internal  processes,  though  not  necessarily 
formalized 

meta-level  issue:  what  are  we  mcducing? 

a  PTl  (Public  Tool  Int^ace) 

a  POM  (Public  Object  Manager) 

a  PCM  (Public  Control  Manager) 

a  PPM  (Public  Process  Manager) 

swapability  issue 

pe^le  buying  tools 

want  multiple  vendors  intearated  at  all  times  in  their  environment 

tools  yankM  in  and  out  heuer/skelter? 

editors  usually  done  so 

other  tools  usually  not  so  swappable 

usually  working  with  multiple  vendors,  e.g.  both  verdix  and  telesoft, 
over  year-by-year  replacabiliQ^ 
more  encompassing  tools  are  harder  to  replace/swap 
less  encompassing,  narrow  tools  are  easy  to  replace/swap 
combinability  issue  different  from  swapability 

combination  should  not  be  assumed  because  of  swapability 

charge  of  the  day  -  gather  info  to  write  IRAC. 
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Integnitioii  Framework  Structure 
runs  on  Unix,  OS/2,  VMS 
Observations  of  IPSE 

politics  and  economics  more  important  than  techy 
IPSE  Reqmts  and  Attribution 

IPSE  should  map  onto  oiganixation 
can  be  introduced  incrementally 

presentation  integration  w/  common  look&feel 
put  in  place,  pilot  project  use  starts  small,  grows; 
(softbench  starts  small  and  can  grow) 
someone  services  the  entire  solution 


not  only  at  installation  but  over  time 
(people  don't  want  to  pay  for  a  lot  of  "glue") 
(framework  provided  by  tool  vendors) 
Questions  of  Tool  Integration  Issues 

doubts  of  a  common  rejpository:  more  distributed  data 
user  inteifaces  -  what  i^d? 


adaptable  to  new  technologies 

who  does  and  who  supports  the  integration? 

Capabilities  provided  by  Framework  -  user/tool  vendor  concerns 
object  storage  and  object  relationship  mgmt 

fine-level  lining  would  be  ^ce,  but  not  sure  of  how 
capabiliQ^  will  by  used  (need  or  want) 
requirement:  tools  need  to  export  internal  UIDs 
true  control  integration 
security/workflow  -  policy  issue 

integrity  requirements  across  the  board 
-  "don't  lose  my  data" 
common  user  interface 


toolkit  to  build  one  around  products 
lioensiqg  capabilities 

license  server  has  to  be  shipped  with  the  products  now 
since  it  is  not  common  across  platforms 
also,  broker  different  kinds  of  services 
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integrated  link  end  messege  menagefflent  framework 

combine  link  management  and  message  switching  in  one  box 
links  between  UlDs  of  objects  and  tools 
emergiim  Standards 

Substrate  TeuhnolMv  (substrata  is  operating  system) 

Integration  agent,  GUI,  OMS  components  of  a  CASE  Framework 
should  not  be  optional  products  (users  don't  want  to  pay 
pay  for  glue) 

Ubiquity  e  Standard  (if  everyone  has  it,  its  a  standard) 


SUMMARY  (by  HF) 

Integrated  Technology  -  From  Platform  Vendor 

-  Dependably  Present 

Baby  Steps  -  UI  Look  A  Feel 

•  Pilots  First 

Data  In^gration  -  Concerned  About  Performance 

-  Granularity 

-  Non-Penmsive  Repositories 

-  Tools  Give  UIDs  on  Private  Data/Public 
Relationship  Mgmt 
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a&fiAK. 

Issues  to  revisit  from  1st  PCIS  Workshop 


T6 

CM 

T7 

Tool  CommuoicatiQo 

TIO 

0-0 

Til 

loteroperabiliQr  A  Language  Binding 

T12 

Net 

T13 

UI 

T15 

Data  exchange  between  enwonments 

T16 

Licensing  A  accounting 

T17 

Net  based  help 

Tl:  What  should  PCIS  provide? 

do  we  need  an  OMS? 

NW:  YES 

course  grained  granularity  versus  fine  grained? 

NW:  we  just  want  to  get  a  blob  and  manipulated  it.  we  want  control  over 
the  fine  grained  data,  i  would  like  a  fine  grained  repository  for  both 
quety  access  attdiat  fast  access,  we  need  the  ability  to  scale. 

we  need  some  words  like  FRAC  d.4  dealing  with  degrees  of  granularity  and 

defioicions  of  granulariQr.  presentation  integration? 

NW:  the  war  is  over,  we'll  just  choose  motif  or  open  look,  adopt  one  or  two 
of  the  s^le  guides  and  run.  take  help  as  an  example. 

HK:  in  london,  some  tool  vendors  were  reluctant  to  adopt  any  tool 

interface,  because  of  the  market,  point  2  was  that  motif  wasn't  at  a 
high  enough  level. 

NW:  once  i  get  past  the  window  dressing,  i've  got  the  control. 

HF:  X  is  too  low  level,  look-and-feel  is  not  alike  at  all ,  and  if  i  take 

current  tool  building  kits  (EAST.  Atherton),  i  get  different  look-and-feel. 

BM:  why  should  PCIS  choose  on  existing  standard? 

HF:  i  think  PCIS  is  in  deep  yogurt  if  it  does,  but  if  the  users  want  to  plug 
and  play,  we  have  to  do  something  about  this  issue. 

BM:  if  we've  chosen  std  A,  and  if  in  1998  stds  A  and  B  are  equally  widely 
used,  tools  will  need  to  be  built  to  use  both. 

NW:  if  we  pick  one,  and  design  for  it,  and  the  other  becomes  the  standard , 
we  end  up  in  deep  trouble,  we  have  to  design  for  both. 

All:  so  do  we. 

BM:  it  does  the  PCIS  effort  no  good  to  choose  a  OUI  standard,  we  can  only 
hurt  ourselves  -  if  we  choose  right,  so  what,  and  if  we  choose  wrong, 
we  get  hurt. 

HF:  so  PCIS  needs  some  kind  of  style  to  standardize  on  some  emerging 

stondird.  we  don't  necessarily  wont  X. 
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LI;  so,  how  much  should  PCIS  commit  to?  if  PCIS  commits  itself  to  too 
much  in  any  area,  PCIS  will  have  to  track  the  tech  in  that  area  and 
keep  up  with  it. 

HF:  I  stUl  like  what  i  wrote  about  technology  tracking.  If  it  gets 

embedded  in  silicon  it  can  be  a  standard;  if  four  or  five  standards 
emerge,  nick  will  have  to  write  tools  that  target  all  of  those  stds. 

NW:  but  i  don't  want  to  standardize  on  a  least  common  denominator. 

when  i  want  to  do  somethiim  more  sophisticated  than  motif  allows, 
that  forces  me  down  to  the  ^ib  level,  and  i  don't  want  to  have  to 
do  more  of  that  than  i  do  know. 

CM 

NW:  essentially,  i  disagree  that  there  is  no  consensus,  will  PCIS  be 
publishing  anything  about  CM  reference  models  and  versioning 
systems. 

HF ;  i  have  been  involved  in  some  discussions  about  whether  CM  is 
toast  or  coils  in  the  toaster  model. 

NW:  to  me,  CM  can  be  very  tool  specific, 

HK:  but  i  may  want  to  use  whatever  CM  system  is  provided  by  the 
framework/env  i  am  using 

BM:  is  there  a  single  basic  versioning  capability  that  everyone  will  be 
happy  with? 

NW:  are  there  still  religious  issues  about  the  ordering  of  version 
numbering,  etc. 

HF :  YES.  absolutely,  some  people  want  long  transactions,  and  some  people 

want  change  sets,  and  each  is  based  on  a  different  paradigm,  and  that 
should  be  okay. 

JPB;  it  would  still  help  to  have  some  basic  elements  to  allow  tools  to  build  CM 

systems  into  a  frameworkyenvironment. 

HF:  but  there  are  still  several  basic  paradigms  onto  which  to  base  CM 

systems,  if  you're  designing  your  CM  as  a  piece  of  bread,  that's  fine. 

HK:  i  would  like  to  have  versioning  on  both  elementary  and  composite 
objects. 

Tool  eofflffloiii  cation 

HF :  do  we  need  to  get  down  to  defining  point-to-point  message  passing, 

and  a  concrete 

0-0 

Interoperability  and  Language  Binding 

NW:  see  T1 1 .  1  violently  agree  with  this,  this  has  caused  a  lot  of  problems. 

HF :  are  you  willing  to  give  op  performance  and  re-usability  for  this. 

Network 

NW;  the  IRAC  should  be  written  with  heterogeneity  in  mind. 

BM:  i  want  to  be  able  to  think  about  laptop  distribution,  i  want  to  be  able 
to  undock  my  pc  from  one  system  and  dock  it  elsewhere 
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Data  exebaage  between  environments 

BM:  we've  got  CEF,  ultimately  stolen  from  CAIS-A. 

HF ;  but  is  not  a  common  external  format  In  the  manner  of  CDIF 

BM;  also,  if  we're  running  on  heterogeneous  machines,  nnd  we  have 
some  internal  form,  do  we  need  a  different  external  format. 

HF :  in  that  case  you're  talking  about  bits  that  you  might  not  be  able 

to  take  the  information  (in  archive  format)  from  environment  to 
environment. 

NW:  is  this  data  exchange  between  dilferent  PCTE  implementations,  or 
between  PCTE  and  ATIS  (e.g. ) 

HF ;  i  expect  that  the  answer  is  that  it  is  between  different  ones  (PCTE 

and  ATIS) 

Licencing  A  Accounting 

Net  Based  Help 

NW:  I'm  a  bit  concerned  about  these  systems  saying  thou  shalt  have  help 

HF :  and  that  thou  shalt  do  it  my  way.  if  the  tool  builder  is  a  good  help/ 

platform  citizen,  the  tool  must  conform  its  help  to  that  of  the  platform. 

BM:  what's  the  point?  what  should  PClS  do  about  help. 

HF :  if  we're  providing  this  help,  we're  not  going  to  be  very  good  citizens. 

HK:  why  can't  we  wony  about  just  some  basic  help  message  handling. 

Internationalization 

HF:  There  is  much  more  of  a  push,  even  in  the  U.S. ,  for 
internationalization. 
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Wednesday  P.M. 

Success/ Avoidance 

Tabled  for  know  doe  to  lack  of  input/Nick 

Separatability 

EP:  When  i  use  the  OMS  service,  i  only  want  to  have  to  pay  the  price  of 

using  the  OMS  service.  I  don't  want  have  to  pay  the  j^ce  for  process 
control. 

HF:  Should  subsets  of  PCIS  be  allowed  which  do  not  contain  all 
functionality  of  the  PCIS? 

BB:  I  tbinit  it  should  be  possible,  and  that  the  PCIS  documentation  should 
define  levels  of  compatibiliQ^  so  that  framework  implementations  can 
say  that  they  conform  to  the  PCIS  to  such-and-such  a  degree. 

H K:  It  seems  like  it  should  be  possible  to  take  parts  of  the  environment 
out  and  replace  them  later  with  other  paits.  This  is  does  not 
currently  conform  to  the  toaster  model. 

EP:  This  issue  was  also  addressed  at  the  last  Workshop  by  the 

environment  users  group. 

Control  Integration 

HF :  We  need  to  worry  about  what  happens  with  an  externally  defined 

schema.  (By  externally  defined  schema,  this  means  within  the  POM. ) 
There  may  be  different  compilers,  linkers,  etc.  which  are  going  to 
have  their  own  schemas,  and  they  won't  know  the  schema  at  run 
time. 

EP:  The  current  NRAC  require  the  schema  can  be  defined  at  run  time. 

HF:  But  this  is  a  requirement  on  the  framework.  We're  talking  install¬ 

time  binding.  Its  a  requirement  on  tools,  not  on  the  framework. 

EP:  How  do  it  Am  i  expect^  to  provide  my  tools  schema  to  some  other 

tool  that  wants  to  integrate  with  my  tools.  It  doesn't  necessarily 
know  anythi^  about  the  POM  it  is  working  with. 

CR:  As  part  of  the  installation  process,  would  there  be  an  encapsulator 

to  conform  to  the  POM? 

HF :  It's  going  to  need  to  be  there,  but  who's  going  to  build  it? 

BB:  An  interesting  part  of  this  discussion  is  attempting  to  pacify/help 
out  the  users  of  the  next  5  years  so  that  they  don't  ignore  PCIS 
altogether.  What  sort  of  political  mandate  will  their  be  to  use  PCIS? 

HF :  Language  is  much  easier  to  legislate  than  something  where  all  the 
parts  come  from  different  places.  It  does  no  good  unless  you  do 
something  about  mandating  the  parts,  mandating  the  tools. 

PCIS  -  How  mandated 

1)  PCIS  -Parts or aU 

2)  Schemas 
data 
objea 
control 

3)  Process 

d)  Tasks 

Mandming  PCIS  is  not  as  difficult  to  mandate  as  the  rest.  What  good 
is  having  something  mandated  if  no  one  knows  how  its  going  to  be  used. 
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EP:  The  primaty  problem  with  ctirrent  PTIs  is  that  the  user  must  take 

your  tool  and  integrate  the  tool  schema  with  the  site  schema. 

HK:  EAST  as  a  consortium  is  defining  a  common  schema.  IEPO-TA13is 
also  doing  the  same  thing.  It  is  a  very  coarse-grained  schema. 

CR:  the  SWO  on  APSE  is  also  defining  a  schema,  but  at  an  even  coarser 
grain  than  the  previous  tool  example. 

EP:  Even  if  Ubiqui^  exists,  it  is  still  not  interesting  if  there  is  not  some 

agreement  on  the  schema. 

We  do  not  want  to  be  compatible  with  obsolete  standards. 

The  answer  is  that  we  do  not  want  to  be  compatible  with  only 
obsolete  standards. 

Does  PCIS  want  to  choose  standards?  How? 

EP:  This  does  not  seem  like  a  good  idea. 

BB:  It  causes  PCIS  to  follow  up  on  all  emerging  standards. 

HK:  Perhaps  one  solution  is  to  say:  in  this  area  we  choose  this  one, 
and  in  this  area  we  choose  several. 

What  should  PCIS  be?  What  should  the  programme  be?  The  product? 
EP:  After  all  of  this  discussion,  i'm  still  not  sure  what  PCIS  is  supposed 

to  be. 

HF :  I've  been  in  meetings  talking  about  requirements  for  10  years,  and 

we're  still  talking  about  requirements.  It  is  very  interesting  to  go 
out  and  see  some  of  the  early  efforts  in  this  area.  For  instance, 

Nick  ripped  cohesion  apart. 

We  need  to  decide  exactly  what  PCIS  is.  It  is  multiple  choice,  now. 

Some  say  environment  framework,  some  say  PTl 

People  are  currently  both  writing  a  lot  and  complaining  about 
frameworks. 

HK:  We  have  identified  requirements.  Now  we  are  coming  back  to  the 
question  of  what  exactly  is  PCIS,  because  we  have  been  asked  to 
come  up  with  requirements  for  a  product,  and  we  are  unclear  on 
what  exactly  that  is  supposed  to  be. 

We  want  to: 

1 )  Evaluate  the  current  state  of  the  art  (pilot  projects  or 
frameworks) 

2)  Matrix  of  likes  and  dislikes  (this  can  be  subjective) 

3)  Assessment  of  Strengths  and  weaknesses  of  these 
technologies 

4)  Pick  technology  (PTI  or  Framework)  and  PCIS  should 
deHne  a  next  generatioa  of  that  technology. 
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What  flhoald  PCIS  proyideT 

For  OMS,  See  FRAC  sectioo  4.4.  Perhaps  this  section  will  be  taken  as  a 
sutttbog  point;  there  needs  to  be  definitions  for  granularity  and  for  degrees 
of  granoiarity. 

CM 

PCIS  should  lu  s  built  to  allow  the  building  of  different  types  of  configuration 
management  systems. 

Need  versioning  on  both  elementary  and  componte  objects. 

Tool  commaaicatioB 
Need  to  define  separate  layers. 

The  protocol  needs  to  be  abstract  (OSl-like),  as  opposed  to  concrete  (the 
factotialial  expansion  when  new  communication  protocols  ai'e  added) 


0-0 

Interoperability  and  Language  Binding 

Higher  class  structures  constncts  the  ability  for  re  -use  of  tools. 

Network 

Heterogeneous  network:  IRAC  should  be  prepared  with  heterogeneity  in  mind. 
(PCEorDistiib.  ???) 

Data  exchange  between  environments 

Licencing  A  Accounting 

Net  Based  Help 

Internationalization 
both  icons  and  text 
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Seutrabili^ 

PClIS  should  iftcilluite  to  the  mudmum  degree  the  decoupling  rd  functional  areas  such 
that  functional  paits  can  be  used  separately. 

AtJenstioakurtAe  deco^itifofthefkMetioaalareatthatiiretobe  coaaunedia  a 
PTIfyaou^  aa  mpiemematioa  of PdS. 

Onoap  mJmaua  (maitgvntioa  /erWr  of  PC/S  compatibility.  A  \x>id  nutdom  subsets. 
Modular  aon'aoaoiitkic  (“poly/irldc "?)  Pramework. 

Puactioasd parts  should  ha  rv  all  ed  their  eompoaeats. 

The  I*CIS implemetttatioa  can  be  built  under  modularly. 


Success  Avoidance 

General 

Needs  to  reduce  my  trorkload.  Implementing  PCIS  does  not  make 

Needs  to  reduce  my  risk.  sense  if  there  is  not  a  large 

Availabili^  market  for  it. 

Compatible  with  existing  standards  Difficult  copyright/License  issues 

Schema  control  should  not  put 

Platform  Support  -  Franiwork  one  vendor  at  the  mercy  of 

prodded  by  supplier  another. 

Corporate  Backing.  Platform  supplier  "forcing"  use  of 

a  particular  framework  arch 

Ubiquity  Unique 

Impact  to  Compute  Center  Operations 
Impaa  to  Projea  Schedules 

Low  Cost/Seat  High  Cost/Seat 


integration 

-  internally  is  a  must 

-  externally  it  is  nice,  and 

only  more  important 
if  customers  are 
asking  for  it. 
Sufficient  market 


Customer  needs  PCIS  installed 


PCIS'  Small  Market 
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PCIS  A  Ezterttal  Standards 

1)  They  change 

2)  Do  they  spply  at  the  correct  level 

3)  Do  they  replace  PCIS 

4|)  Choose  one  \ 

Make  one  >  want  as  few  as  possible 
UseaU  / 

we  don't  want  make  one  because  making  one  effectively  adds 
one  more  to  the  list,  aggrevatif^  the  chmces. 

Define  the  areas  in  which  PCIS  needs  to  make  choices  about  standards. 

These  choices  may  be  single  or  multiple,  depending  on  the  area. 

The  preference  is  to  be  able  to  choose  the  minimum  number  of  standards. 

What  is  PCIS  (programme  or  product)? 

A  subjective  evaluation  of  tool/environment  by  users  and  vendors. 
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Object  Management  System 
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NISTIPCISIIWCASE  ATTENDANCE  3^7  JUNE  1991 


Ackerman,  Barry  J.  NISTIPCISIIWCASE 

Cadre  Technologies  Inc, 

222  Richmond  Street 
Providence,  RI  02903 

PHONE;  (401)351-5950;  FAX:  (401)351-7380 
EMAIL: 


Ali,  Yawar  NISTIPCISIIWCASE  2-c 

Bell-Northern  Research  Ltd. 

P.O.  Box  3511,  Station  C 
Ottawa,  Ontario 

PA  M  ADA  K1YAH7 

PHONE:  613/763-7741;  FAX:  613/763-3305 
EMAIL: 


Andersen,  Jorgen  B.  NISTIPCIS  a,d 

Honeywell 

P.O.  Box  21111 

Phoenix,  AZ  85036 

PHONE:  602-436-1712;  FAX:  602-436-2252 
EMAIL: 


Anderson,  John  NIST  3 

Boeing  Defense  and  Space  Group 
P.O.  Box  3999,  M/S  87-37 
SeatUe,WA  98124-2499 

PHONE:  (206)7734319;  FAX: 

EMAIL:  anderson@stars.boeing.com 


Audras,  Francois  NISTIPCIS  I,  a 

SYSECA 

315  bureaux  de  la  Colline 
92213  St  Cloud 
FRANCE 

PHONE:  33  1  49  1 1  70  00;  FAX:  33  1  49  1 1  76  45 
EMAIL;  Francois.Audras@lv.bull.fr 


LEGEND: 

8.7/9 1  5:01  PM 


/.  Object  Managetnent 

2.  Process  and  Task  Management 

3,  interface  &.  Platform  Services 


4.  User  interface 


a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

e.  Needs  of  the  Environment  Supplier 


d.  Needs  of  the  Environment  Users 
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NISTIPCIS/IWCASE  ATTENDANCE  3-7  JUNE  1991 

Att§ndlnf  Which  Workshoo(s)  A  Warktne  Grsun/sl 

Bagwill,  Robert  H.  NIST 

NIST 

Bldg.  225,  Room  B266 
Gaidiersburg,  MD  20899 

PHONE:  301-975-3282;  FAX:  301-590-0932 
EMAIL:  rbagwiil(S)nist.gov 


Baker,  Thomas  G.  NISTIPCISIIIWCASE  1,2,3,4-a 

Boeing 

M/S  6H-03 

P.O.  Box  24346 

Seatae,WA  98124 

PHONE:  206-234-6234;  FAX:  206-234-0256 
EMAIL:  tom@asfars.boeing.com 


Balzer,  Robert  NIST/PCIS  3-c 

UCS-Information  Sciences  Institute 

4676  Admiralty  Way 

Marina  del  Rev,  CA  90291-6695 

PHONE:  213-822-1511,  ext.  249;  FAX:  213-823-6714 
EMAIL:  balzer@isi.edu 


Baudoin,  Claude  R.  PCIS  d 

National  Semiconductor,  M/S  10-145 

2900  Semiconductor  Drive 

P.O.  Box  58090 

Santa  Clara,  CA  95052-8090 

PHONE:  (408)721-6678;  FAX:  (408)732-9654 
EMAIL:  BAUDOIN%SCVXCL.DNET@GPO.NSC.COM 


Beitz,  Kirk  NISTIPCISIIWCASE  3,4-a 

Intermetrics,  Inc. 

733  Concord  Ave. 

Cambridge,  MA  02138 

PHONE:  617-661-1840  ext  4525;  FAX: 

EMAIL:  johndoe@inmeLinmetcom 


LEGEND: 

8/7/91  5:01  PM 


NIST  1SEE  Working  Grauas: 

1.  Object  Management 

2.  Process  and  Task  Management 

3.  Interface  &  Platform  Services 

4.  User  Itaerfoce 


PCIS  Worklne  Groups: 

a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

c.  Needs  of  the  Environment  Supplier 

d.  Needs  of  the  Environment  Users 
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NISTIPCISIIWCASE  ATTENDANCE  3-7  JUNE  1991 


Belz,  Frank  PC/S  d 

TRW  R2/2062 

One  Space  Park 

Redondo  Beach,  CA  90278 

PHONE:  213-812-0854;  FAX:  213-812-7147 
EMAIL:  belz@trwarcadia.sdd.trwxom 


Black,  Eric  PCIS  c 

Atherton  Technology 
1333  Bordeaux  Dr. 

Sunnyvale,  CA  94089 

PHONE:  (408)734-9822;  FAX:  (408)744-1607 
EMAIL:  ericb@atherton.com 


Bladen,  Jim  PCIS  a 

Telesoft 

5959  Cornerstone  Court  West 
San  Diego,  CA  92121 

PHONE:  619-457-2700;  FAX:  619-452-2117 
EMAIL: 


Borowski,  Bob  NISTIPCISIIWCASE  2-a 

Protocol,  A  Division  of  Zycad 
500  International  Drive 
Mount  Olive,  NI  07828 

PHONE:  201-347-7900;  FAX:  201-347-0303  fax 
EMAIL: 


Boswell,  Murrah  NISTIPCIS  1 ,2 ,3 ,4-a,b,c,d 

Navajo  Technologies,  Inc 
Navajo  Nation 
Leupp,  AZ  80035 

PHONE:  602/686-6391;  FAX:  602/686-6227 
EMAIL: 


Boudier,  Gerard  NISTIPCIS  c 

Gie  Emeraude  c/o  Bull  58F 

68  route  de  Versailles 

78430  Louveciennes 

FRANCE 

PHONE:  33  1  39  02  40  93;  FAX:  33  1  39  02  42  06 
EMAIL:  Gerard.Boudier@lv.bull.fr 


LEGEND: 

8/7/91  5:01  PM 


1 .  Object  Management 

2.  Process  and  Task  Management 

3.  Interface  &.  Platform  Services 


4,  User  Interface 


a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

e.  Needs  of  the  Environment  Supplier 


d.  Needs  of  the  Environment  Users 
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I  NIST/PCIS/IWCASE  ATTENDANCE  3-7  JUNE  1991  1 


Aumdinr  Wnrkxhoo(!t\  A  Warkinp  Giouoisl 

Bourguignon,  Jean  Philippe  PCIS  a,c 

SFGL 

14  rue  de  la  Ferme 
92100  Boulo  Gne 
FRANCE 

PHONE:  33  1  47  61  05  20  FAX:  33  1  47  61  92  15 

EMAIL:  Jean.Philippe.Bourguignon@sfgl.rlgl.fr  (?) 


Bremeau  Christian  NIST/PCIS  c 

GEE  Emeraude 
c/oBuU  (bat58F) 

68  route  de  Versailles 
78430  Louveciennes 
FRANCE 

PHONE:  33  1  39  02  40  56;  FAX:  33  1  39  02  42  06 
EMAIL:  Christian.Bremeau@lv.bull.fr 


Bruso,  Kelsey 
Unisys  Corporation 
P.O.  Box  64942 
MS:  4762 

St  Paul,  MN  55164-0942 

PHONE:  612-635-3478; 
EMAIL: 


Canning,  A 
ERA  Technology  LTD 
Cleeve  Road 
Leatherhead,  Surrey 
ENGLAND 

PHONE:  0  372  374151; 
EMAIL: 


NIST!  PCIS  3-b,c 

FAX:  612-635-3899 

PCIS  d 

FAX:  0  372  374496 


Carlson,  Susan  PCIS  d 

AdalC 

%  HT  Research  Institute 
4600  Forbes  Blvd. 

Lanham,MD  20706 

PHONE:  703/685-1477, 800/Ada-icll;  FAX:  703/685-7019 
EMAIL:  carlsons@ajpo.sei.cmu.edu 


LEGEND: 

8/7/91  5:01  PM 


NIST  ISEE  WorkiHP  Groups: 

1.  Object  Management 

2.  Process  and  Task  Managemertt 

3.  Interface  i.  Platform  Services 

4.  User  Interface 


PCIS  Workine  Graurtsi 

a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

c.  Needs  of  the  Environment  Supplier 

d.  Needs  of  the  Environment  Users 
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NIST/PCIS/IWCASE  ATTENDANCE  3-7  JUNE  1991  | 


AUtndinp  Whish  WorkshoBfs:)  &  Worklne  C.rouBix) 


Carney,  David  NIST/PCIS  1  ,c 

Lisdtute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria,  VA  223 11-1 772 

PHONE:  703-845-6648;  FAX:  703-845-6848 
EMAIL:  carney@ida.org 


Cerino,  Deborah  NIST/PCIS  1-d 

Rome  Laboratory 

RUCOEE 

Griffiss  Air  Force  Base,  NY  13441 

PHONE:  315/330-2054;  FAX:  315/330-3911 
EMAIL:  cerino@softvax.radc,af.mil 


Clow,  Geoff  NIST/PCIS/IWCASE  2,c 

Softech,  Inc. 

Suite  100 

10875  Rancho  Bernardo  Road 
San  Diego,  CA  92127 

PHONE:  619-451-9320;  FAX:  619-451-9327 
EIvlAIL:  clow@nosc.mil 


Colket,  Currie  PC  IS  3,d 

AJPO 

The  Pentagon  Room  3E1 14 
Washington,  D.C.  20301-3081 

PHONE:  703-614-0209;  FAX:  703-685-7019 
EMAIL:  colket@ajpo.sei.cmu.edu 


Costa,  Claudio  PCIS  d 

Alenia  Spa 

Via  Tiburtina  KM  12.4 
POB  7083-00131  Roma 
ITALY 

PHONE:  +39  643602520;  FAX:  +39  64131091 
EMAIL: 


LEGEND: 

8/7/91  5:01  PM 


mST  ISEE  Working  Grouns: 

1.  Object  Management 

2.  Process  and  Task  Management 

3.  Interface  &  Platform  Services 

4.  User  Interface 


PCIS  Worklnt  Groups: 

a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

c.  Needs  of  the  Environment  Supplier 

d.  Needs  of  the  Environment  Users 
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NISTIPCISIIWCASE  ATTENDANCE  3^7  JUNE  1991 


AtUndlne  Which  Workshoofs)  A  Working  Groupis) 


Cox,  Gary  PC  IS  a,b 

IBM  Coip. 

525  Lascade 

Colorado  Springs,  CO  80903 

PHONE:  719/520-3028;  FAX: 

EMAE.: 


Cristina,  Jackie  NISTIPCISIIWCASE  l,3-a,b,c,d 

US  Army 

Attn:  CSSD-SA-BT/Jackie  Cristina 
P.O.  Box  1500 
Huntsville,  AL  35807-3801 

PHONE:  205-955-3861;  FAX:  205-955-3994 
EMAIL: 


Cuoco,  Ed  NISTIPCISIIWCASE  2,4-a,b 

Digital  Equipment  Corp. 

1 10  Spit  Brook  Rd.  ZK02-  1/Ml  1 
Nashua,  NH  03062 

PHONE:  603-881-2338;  FAX:  603-881-0120 
EMAIL:  cuoco@tle.dec.com 


Cureton,  W.H.  NISTIPCISIIWCASE  1-b 

Sun  Microsystems 
PALI  424 
2550  Garcia  Ave. 

Mountain  View,  CA  94043 

PHONE:  415-336-2822;  FAX: 

EMAIL:  bill.cureton@corp.sun,com 


Davis,  Hugh  NISTIPCIS  3  ,d 

ICL 

Eskdale  Road 
Winnersh 
Wokingham 
Berkshire  RGll  5Tr 
ENGLAND 

PHONE:  -mW  734  693131;  FAX:  -h44  734  697636  fax 
EMAIL:  hfd@win.icl.co.uk 


LEGEND:  NIST  1SEE  Working 

1.  Object  Management 

2.  Process  and  Task  Management 

3.  Interface  &  Platform  Services 

4.  User  Interface 


ECIS  Working  Groans: 

a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

e.  Needs  of  the  Environment  Supplier 
d.  Needs  of  the  Envirorment  Users 


8^/91  5:01  PM 


I  NiST/PCISimCASE  ATTENDANCE  3-7  JUNE  1991 


AUtndimL.  WMeh.^WartihiUih)  &  Workiitp  nroupfs) 


Da^ves,  John  PClS  a,b,c,d 

ICL 

Eskdale  Road,  Winnersh 
Wokingham 
Berkshire  RGl  1  5TT 
UNITED  KINGDOM 

PHONE:  +44  734  693131;  FAX:  +44  734  697636  fax 
EMAIL:  sjd@win.icl.co.uk 


Denson,  David  NIST 

Texas  Instruments 

2750  Prosperity  Ave.,  Suite  100 

Fairfax,  VA  22031 

PHONE:  703-849-1450;  FAX:  703-560-5803 
EMAIL: 


Drake,  Dick  NIST  (Did  Not  Attend) 

IBM 

800  N.  Frederick  Ave. 

M'S  18213F11 
Gaithersburg,  MD  20879 

PHONE:  301-240-6149;  FAX: 

EMAIL:  ddrake@ajpo.sei.cmu.cdu 


Dutton,  Jim  NISTIPCIS  4-c 

International  Software  Systems 

9430  Research  Blvd.  Echelon  HI  Suite  250 

Austin,  TX  78729 

PHONE:  512-338-5729;  FAX:  512-338-5757 
EMAIL:  uucp:  issildutton 


Earl,  Anthony  NISTIPCIS  2 

Hewlett-Packard 

HP  L,abs.  Filton  Road,  Stoke  Gifford 

Bristol  BS12  6QZ 

ENGLAND 

PHONE:  +44  0  272  799910;  FAX:  +44  0  272  790554 
EMAIL:  ane@hplb.hpl.hp.com 


LEGEND: 


snm  5:01  PM 


HIST.  ISEF, .  Waetiiu .  Groiusi 

1.  Object  Management 

2.  Process  and  Task  Management 

3.  Interface  A.  Platform  Services 

4.  User  Interface 


a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

c.  Needs  of  the  Environment  Supplier 

d.  Needs  of  the  Environment  Users 
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I  NIST/PCIS/IWCASE  ATTENDANCE  3-7  JUNE  1991 


Atttndinp  Which  WorkshoD(s)  -(6-  WorklnF  Ground} 

Ecimouic,  Dusan  NISTIPCIS  1 ,2 

425  Market  Street 
San  Francisco,  CA 

PHONE;  415/545-2671;  FAX:  415/545-2813 
EMAIL: 


Ekman,  Robert  W.  NISTIPCIS  Ic 

IBM  STARS 

800  N.  Frederick  Ave. 

Gaithersburg,  MD  20879 

PHONE:  301-240-6431;  FAX: 

EMAIL:  ekinanb<2)rckvm  1  .vnet.ibm.com 


Ett,  William  T  NISTIPCIS  2 

19724  Drop  Forge  Lane 
Gaithersburg,  Nffi  2087 

PHONE:  301/245-6322;  FAX:  301/240-6873 
EMAIL;  ettb(2)wmavm7.iinusi. ibm.com 


Fischaleck,  Maria  PC  IS  a,d 

lABG 

Einsteinstr  20 
8012  Ottobrunn 
GERMANY 

PHONE:  +49  89  6088-3560;  FAX:  +49  89  6088  3418 
EMAE.;  uucp:  uuido.uucp!iabgsz!sztsun04!fischal 


Fischer,  Herm  NISTIPCISIIWCASE  I,2,3-a,d 

Mark  V  Systems  Limited 
16400  Ventura  Blvd.,  Suite  303 
Encino,CA  91436 

PHONE:  818-995-7671;  FAX:  818-995-4267 
EMAIL:  hermixlfischer@rand.org 


Gibbons,  Mark  NISTIPCIS  1 ,2-d 

British  Telecommunications 

BT  Laboratories 

Martlesham  Heath 

IPSWICH  IPS  7RE 

ENGLAND 

PHONE:  +44  473  642056;  FAX: 

EMAIL:  mgibbons@axion.bt.co.uk 


LEGEND:  NIST  ISEE  Working  Groups: 

!.  Object  Management 

2.  Process  and  Task  Management 

3.  Interface  A.  Platform  Services 

8/7/91  5:01  PM  4.  User  Interface 


PCFS  Workine  Groups: 

a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

e.  Needs  of  the  EnvironmerU  Supplier 
d.  Needs  of  the  EnvironmerU  Users 
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NIST/PCIS/IWCASE  ATTENDANCE  3-7  JUNE  1991  | 


Atttndinv  Which  Workshopfs)  &  Working  art,an(x\ 

Goldman,  Neil  M.  NISTIPCIS 

USC/Infonnation  Sciences  Institute 
4676  Admiralty  Way 
Marina  del  Rey,  CA  90292 

PHONE:  213-822-1511  x247;  FAX:  213-823-6714 
EMAIL:  goldman<S)isi,edu 


Gutzmann,  Kurt  NISTIPCIS  1 ,2 ,3 ,4 ~a,b,c,d 

Softech 

1300  Hercules,  Suite  105 
Houston,  TX  77058 

PHONE:  713-480-1994;  FAX:  713-480-1994 
EMAIL:  gut2mann@ajp0.sei.cmu.edu 


Haddad,  Ranwa  NISTIPCIS/IWCASE  1,2,3,4-d 

Aerospace  Coiporation 

M/S  M8/166 

P.O.  Box  92957 

Los  Angeles,  CA  90009-2957 

PHONE:  213-336-3438;  FAX:  213-336-3538 
EMAIL:  haddad@aerospace.aero.org 


Hanrahan,  Robert  P.  NISTIPCIS/IWCASE  3-c 

US  Air  Force  STSC 

OOALOnSAC 

BlOOBay  G 

HiU  AFB,  UT  84056 

PHONE:  801-777-8045;  FAX:  801-777-8069 
EMAIL:  hanrahan@oodis0 1  .af.mil 


Harkleroad,  Lt.  Joseph  E.  NISTIPCIS 

Naval  Post  Graduate  School 
Monterey,  CA 

PHONE:  408-646-2056;  FAX:  4  08-646-2760 
EMAL: 


Hart,  Hal  NIST/PCIS/IWCASE  2-d 

TRW  R2/2062 

One  Space  Park 

Redondo  Beach,  CA  90278 

PHONE:  213-812-0661;  FAX:  213-812-7147 

EMAH,:  halhart@ajpo.sei.cmu.edu,  stars@trwarcadia.sdd.trw.com 


LEGEND: 


8/7/91  5:01  PM 


NIST  ISEE  Worklne  OrouBs: 
/.  Object  Management 

2,  Process  and  Task  Management 

3,  Interface  &.  Platform  Services 

4,  User  Interface 


fCIS .  Working  Greunii 

a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

c.  Needs  of  the  Environment  Supplier 

d.  Needs  of  the  Environment  Users 


im 


Hartman,  Don  NISTIPCIS  l,4-a,b,c,d 

Hal  Computer  Systems 
8920  Business  Park  Drive 
Austin,  TX  78759 

PHONE:  512-794-2855;  FAX:  512-794-8737 
EMAIL:  halaus!dwh(a)hal.com 


Hayter,  Ken  PCIS  c 

Defence  Research  Agency  (UK) 

RSRE 

St.  Andrews  Rd. 

Malvern 
Worcestershire 
WR14  3PS 
UNITED  KINGDOM 

PHONE:  +44  684  89  5836;  FAX:  +44  684  89  4540 
EMAIL:  KWH%heimes.mod.UK@relay.MOD.UK 


Horton,  Michael  NIST/PCISIIWCASE  l~c 

Unisys  Corp. 

P.O.  Box  517 
Paoli.PA  19301 

PHONE:  215-648-2527;  FAX;  213-648-2288 
EMAIL:  horton@prc.unisys.com 


Jenkins-Bnafa,  Jovita  NISTIPCIS  l,4-a,d 

TRW 

1  Space  Park  R2/2044 
Redondo  Beach,  CA  90278 

PHONE:  213/812-1795;  FAX:  213/812-7147 
EMAIL: 


Kavianpour,  Mansour  NISTIPCIS  2 -ax 

IBM  Canada  Ltd. 

895  Don  Mills  Road 
North  York,  Ontario 
M3C  1V7 
CANADA 

PHONE:  416/448-2379;  FAX:  416/448-2114 
EMAIL:  mansour@torolabs.vnet.ibm.com  (?) 


LEGEND:  NIST  ISEE  Warklnr  Grouoi: 

1.  Object  Management 

2.  Process  and  Task  Management 

3.  Interface  &  Platform  Services 

4.  User  Interface 


eClS  Working  Creuns; 

a.  Needs  of  the  Tool  Builders 

b.  Needs  of  the  Platform  Supplier 

c.  Needs  of  the  Environment  Supplier 

d.  Needs  of  the  Environmera  Users 


8/7/91  5:01  PM 


NIST/PCISinVCASE  ATTENDANCE  3-7  JUNE  1991 


Keith,  Sharon 
NOSC 

271  Catalina  Blvd. 

San  Diego,  CA  92152 

PHO>JE:  619/553-6858; 
EMAIL:  keith@nosc.niil 


NISTIPCISIIWCASE 


FAX;  619/553-5799 


Kerner,  Judy 
The  Aerospace  Coxp. 
MSM8/117 
P.O.  Box  92957 
Los  Angeles,  CA  90009 
PHONE:  213-3 
EMAIL:  kernel 


NIST /PC  IS  l,3,4-a,d 


213-336-3131;  FAX:  213-336-3538 
kemer@arecibo.aero.org 


Keus,  Hans  E.  PC  IS  a,c 

Westmount  Technology 

P.O.  Box  5063 

2600  GB  Delft 

THE  NETHERLANDS 

PHONE:  +31  15  610815;  FAX:  +31  15  565701 
EMAIL:  uucp:  hp4nl!wmt!hake 


King,  James 

Boeing  Defense  and  Space  Group 
P.O.  Box  3999,  MS  87-37 
Seatae,WA  98124-2499 

PHONE:  206-773-4316;  FAX: 
EMAIL:  jk@stars.boeing.com 


NIST/IWCASE 


206-773-4946 


La  Basse,  Daniel  T 
407  Shirleen 
Seabfook,  TX  77586 

PHONE:  713/333-0947; 
EMAIL: 


NISTfPCIS 


FAX:  713/333-2813 


Leary,  John  NISTIPCISIIWCASE 

Martin  Marietta  Corp. 

4795  Meadow  Wood  La. 

Chantilly,  VA  22021 

PHONE:  703-802-5604;  FAX.  703-802-5464 
EMAIL:  learyj@ajpo.sei.cmu.edu 


LEGEND.' 


8/7/91  3:01  PM 


1.  Object  Managemeni 

2.  Process  and  task  Mmagvneta 

3.  Interface  &  Platfcrnt  Services 

4.  User  Inier/ace 


a.  Needs  ej  the  Tool  Bmiders 

b.  Needs  oj'  the  Platform  Supplier 

e.  Needs  rtf  the  Environment  Supplier 
d.  Needs  of  the  Environment  Users 
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I  '  NIST/PCISIlWCASE  ATTENDANCE  3-7  JUNE  1991  I 


Autndlmp  Which  Workxhoo(s)  &  Working  OrMUttlsl 

Leon,  Jeff  NIST/PCISflWCASE  l,3,4.a,d 

Hal  Computer  Systems 
8920  Business  Park  Drive 
Suite  300 

Austin.  TX  78759 

PHONE:  512-794-2855;  FAX:  512-794-8737 
EMAIL: 


Lindquist,  Timothy  E.  PC  IS  1-d 

Computer  Science  and  Engineering  Dept 
Arizona  State  University 
Tempe,  AZ  85287-5406 

PHONE:  602-965-2783;  FAX:  602-965-2751 
EMAIL:  lindquis@asuvax.eas.asu.edu 


Longden,  D.  PCIS  4~d 

UK  Mod 

Room  44!  Turnstile  House 
98  High  Holbom 
LongdonWClV6LL 
ENGLAND 

PHONE:  +44  71  430  533 1 ;  FAX:  +44  71  430  5650 

EMAIL: 


Matsubara,  Tomoo  NISTtPCIS  NUMBERLETTER 

6-81  ONOE-MACm, 

NAKA-KU,  YOKOHAMA 
JAPAN 

PHONE:  +81-45-681-2111;  FAX:  +81-45-681-4099 
EMAIL:  Matsu@aqu.hitachi-sk.co.jp 


McKee,  Gary  NISTIPCIS  a,  b,  c4 

McKee  Consulting 
PO  Box  3009 
Utaeton,CO  80151 

PHONE:  303/795-7287;  FAX: 

EMAIL:  gmckee@ajpo.sei.cmu.edu 

EXPRESS  MAIL;  1 1 1  West  Fremont  Ave.,  Litdeton,  CO  80120-4242 


LECilND: 

817/91  5:01  PM 


MST  /SEE  Warkimt  C.rauai: 
l.Objtet  Maruittmad 

2.  ProcMss  mi  Task  Mmoftmmt 

3.  iHtsifact  A  Platform  Stnncas 

4.  User  interface 


PCIS  Wnrkint  CraMBSz 
m.  Needs  of  the  Tool  Builders 
b.  Needs  the  Platform  Supplier 
e.  Needs  ^  the  Esntironment  Supplier 
d.  Needs  the  Environmmt  Users 
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I^ISriPCISlIWCASE  ATTENDANCE  3-7  JUNE  19^1 


4(lCfirf/iif  Which  Wt>rkshoa(s)..A.^W.orkinB  Graua(sl 

McQuage,  Neil  NISTIPCISIIWCASE  1-c 

Boeing  Defense  and  Space  Group 
P.O.  Box  3999,  MS  87-37 
Seattle,  WA  98124-2499 

PHONE:  206-773-4310;  FAX:  206-773-4946 
EMAIL:  mcquage@stars.boeing.com 


Memmi,  G.  NlST/PCIStlWCASE  l,4^c 

BuU 

300  Concord  Rd. 

MSMA30/8214 
Billerica,  MA  01821 

PHONE:  508-294-2617;  FAX;  508-294-4361= 

EMAIL:  memmi@pws.bull.com 


Milligan,  Janies  NIST!  PC  IS 

Rome  Laboratoiy 

RUCOEE 

Griffiss  Air  Force  Base,  NY  13441 

PHONE:  315/330-2054;  FAX:  315ri30-3911 
EMAIL:  milligan@softvax.radc.af.mil 


Minot,  Regis 
Gie  Emeraude  c/o  Bull 
68  route  de  Versailles 
78430  Louveciennes 
FRANCE 

PHONE:  (+33)  1.39.02.  51.16; 
EMAIL:  Regis.Minot@lv.bull.fr 


NISTIPCIS  c 


FAX:  (+33)  1.39.02.  42.06 


Morin,  Joseph  NIST  2,3-a,c 

Software  &igineering  Institute 
Carnegie  Mellon  University 
5000  Forbes  Ave. 

Pittsburgh,  PA  15213-3890 

PHONE:  412-268-8594;  FAX:  412-268-5758 
EMAIL:  jfm@sei.cmu.edu 


LEGEND: 

inm  5:01  PM 


NIST  ISEE  Warklmr  CrouBM: 
I.Objact  Managtmtnt 

2.  Proctss  and  Task  Managanent 

3.  Interfaca  A.  Platform  Sarvicts 

4.  Usrr  Imerfaee 


PCIS  Working  Grouas: 
a.  Naeds  cf  the  Tool  Builders 
h.  Needs  of  the  PUufmm  Supplier 
e.  Needs  of  the  Environment  Supplier 
d.  Needs  the  Environment  Users 
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NIST/PCISIIWCASE  ATTENDANCE  3-7  JUNE  1991  \ 


Alttmdlnf  Which  WarAsha/>fii  A  Working  GrauoM 

Morron*  M.W.  NISTIPCISIIWCASE  4  (Did  Not  Attend) 

BNR  Europe,  Ltd. 

London  Road 
Harlow,  Essex 
CM17  9NA 
UNITED  KINGDOM 

PHONE:  +44  279  429531;  FAX:  +44  279441551 
EMAIL:  nirm@stl.stc.co.uk 


Mulholland,  Sandra  NISTIPCJS 

Rockwell 

MS  124-211 

400  Collins  Road  NE 

Cedar  Rapids,  lA  52498 

PHONE:  319-395-4047  FAX: 

EMAIL:  smulholl@ajpo.sei.cmu.edu 

Munck,  Robert  G.  NISTIPCIS  l-b 

Unisys 

12010  Sunrise  Valley  Drive 
Reston,  VA  22091 

PHONE:  703/620-7991;  FAX  703/620-7916 
EMAIL:  munck@STARS.Reston.Unisys.COM 

Nolan,  Chris  J.  NISTIPCISIIWCASE 

Technical  Director,  SDT  Italy, 

Digital  Equipment  Corporation, 

Piazza  XX  Settembre,  1 
21 100  VARESE 
ITALY 

PHONE:  +39  332  298460;  FAX:  +39  332  240290 
EMAIL:  nolan@varese.dec.com 


Oberndorf,  Patricia  NISTIIWCASE 

Naval  Air  Development  Center 
Code  7031 

Warminster,  PA  18974-5000 

PHONE:  2^-441-2737;  FAX:  215-441-3225 
EMAIL:  tricia@nadc.navy,mil 


LEGEND: 

%ni9\  5K)1  PM 


mSIL  lSEE  WaHclmm  Gnunt! 

1.  Object  Uanagement 

2.  Proaas  and  Task  Managmnant 
2,lntvfae*  A  Platform  Sorvieas 
4.  Utcr  Intorfau 


PCIS  Warktnm  Groups: 

a.  Naadi  of  the  Tool  Builders 

b.  Nemb  of  the  Platform  Supplier 

e.  Naads  ttf  the  Environment  SuppUer 
d.  Needs  ^  the  Environmtnt  Users 
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I  NISTIPCIS/IWCASE  ATTENDANCE  3^7  JUNE  1991  \ 


AUtndlnM^JgfJdth  JWorkshoD(s)  A  Workini^  Grouofi) 

Ochll,  Hira^i  NIST/PCIS  1,  3 

Hitachi  Software  Engineering  Co.,  Ltd 
6-81  Onoe>ChoNaka’Ku  Yokohama  City 
Kanagawa, 

JAPAN 

PHONE:  0-45-824-2111;  FAX:  0-45-824-0566 
EMAIL: 


Oliver,  Huw  PClS 

Hewlett-Packard 

HP  Labs,  Filton  Road,  Stoke  Gifford 

Bristol  BS12  6QZ 

ENGLAND 

PHONE:  +44  0  272  799910;  FAX:  +44  0  272  790554 
EMAIL:  heo@hplb.hpl.hp.cQm 


Penedo,  Maria  NISTIPCISIIWCASE  1 

TRW  R2/2062 
One  Space  Park, 

Redondo  Beach,  CA  90278 

PHONE:  213-812-0595;  FAX:  213-812-7147 
EMAIL:  penedo@trwarcadia.sdd.trw.com 


Peterson,  Judi  NIST/PCISIIWCASE  I-d 

TRW 

Mail  Station:  HAFB/TOO 
1 104  Country  Hills  Dt. 

Ogden,  UT  84403 

PHONE:  801-773-8938;  FAX:  801-777-8069 
EMAIL:  judip@oodis0 1  .af.mil 


Peterson,  Ron  NIST/PCIS  2-c 

TRW 

Mail  Station:  HAFB/100 
1 104  Country  Hills  Dr. 

Ogden,  UT  84403 

PHONE:  801-773-8938;  FAX:  801-777-8069 
EMAIL:  ronp@oodis0 1  .af .ntil 


LEGEND: 

5:01  PM 


Hin  ISMS  yiarkint  Grom: 

l.ObjKt  Mauuemtiil 
3.  Process  and  Task  Mantzjemant 

3.  Interface  A  Platform  Services 

4,  User  Iraerfaee 


PCIS  Working  Groups: 
a.  Needs  of  the  Tool  Builders 
h.  Needs  of  the  Platform  Supplier 
e.  Needs  of  the  Envuronment  Supplier 
d.  Needs  the  Environment  Users 


775 


I  NISllPCIS/IWCASE  ATTENDANCE  3-7  JUNE  1991 


AtUndlnw  Which  WarAshaBi'si  A  Worklnt  Grouuls) 

Ploedereder,  Erhard  NIST/PCIS  Ua 

Tartan  Inc. 

300  Oxford  Drive  -  Level  4 
Monroeville,  PA  15146 

PHONE:  412-856-3600;  FAX:  412-856-3636 
EMAIL:  ploedere@tartan.com 


Power,  Leigh  NiSTIPCIStlWCASE  2-d 

MCC 

3500  West  Balcones  Center  Drive 
Austin,  TX  78750 

PHONE:  512/338-3480;  FAX:  512/338-3899 
EMAIL:  power@mcc.com 


Printz,  Jacques  PCIS  a,b,c,d 

CR2A 

CGI  Group 

19,  avenue  Dubonnet 

9241 1  Coubevoie  Cedex 

FRANCE 

PHONE:  33  1  47  68  97  97;  FAX:  33  1  47  68  87  8 1 
EMAIL:  printzj@ajpo.sei.cmu.edu 


Pritchett,  Gary  NISTIPCIS/IWCASE  l‘a,b,c,d 

Softech,  Inc. 

Suite  100 

10875  Rancho  Bernardo  Road 
San  Diego,  CA  92127 

PHONE:  619-451-9318;  FAX:  619-451-9327 
EMAIL:  gpritchett@nosc.mil 


Randall,  Charlie  N  1ST ! PCIS UW CASE  l,2,4-a,c,d 

GHGCorp. 

1300  Hercules 
Suite  1 1 1 

Houston,  TX  77058 

PHONE:  713-488-8806;  FAX: 

EMAIL: 


LEGEND: 

3/7/91  5:01  PM 


NIST  ISEE  Warklnm  fintunt- 
/.  Object  Management 

2.  Process  and  Task  Management 

3.  Iraerfoce  A  Platform  Serwces 

4.  User  Interface 


PCIS  Working  Grauns: 
a.  Needs  of  the  Tool  Builders 
k.  Needs  of  the  Platform  Supplier 

c.  Needs  of  the  Environment  Si^pUer 

d.  Needs  of  the  Environment  Users 
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I  NISTIPCISIlWCASE  ATTENDANCE  3-7  JUNE  1991 


Which  WorkshoBfs)  &  Workine  Grouvls.1 
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